Re: port diagnose and xcode

[Joshua Root]

I truly appreciate everyone who maintains things for MP - couldn’t live without 
this stuff.  My initial query was just trying to understand whether ‘port 
diagnose’ was telling me something I should be concerned about.  I think the 
answer was ‘no’.
The message could be improved for that case, certainly. All that check 
does currently is print the message that started this discussion if your 
currently installed version of Xcode is not in the list of versions 
known to work on your OS version: 



If no version of Xcode is installed, it should say something along the 
lines of "You don't have Xcode installed, so you will not be able to 
build the subset of ports that build using Xcode."


It should also check the CLT version but currently doesn't.

- Josh

Re: port diagnose and xcode

[James Secan]

I truly appreciate everyone who maintains things for MP - couldn’t live without 
this stuff.  My initial query was just trying to understand whether ‘port 
diagnose’ was telling me something I should be concerned about.  I think the 
answer was ‘no’.

Jim
3222 NE 89th St
Seattle, WA 98115
(206) 430-0109

> On Mar 11, 2022, at 2:21 PM, Dave Horsfall  wrote:
> 
> On Fri, 11 Mar 2022, Chris Jones wrote:
> 
>> MacPorts is not (just) 'a simple package manager'. Yes, it performs this 
>> function, but first and foremost (and long before we even had binary 
>> tarballs to distribute as a 'package mnager') it is a system for 
>> building packages and their dependencies. To build something you require 
>> a compiler. Many ports will build fine with just the Apple CLT package, 
>> but some indeed require the full Xcode installation in order to be built 
>> (and Xcode also is not just an IDE, but is also a command line build 
>> system).
> 
> I couldn't have put it better myself; the fact that some packages 
> (contributed to MacPorts) require Xcode is hardly MacPorts' fault.
> 
> I dips me lid to the MP maintainers for what is obviously a thankless job.
> 
> -- Dave

Re: port diagnose and xcode

[Dave Horsfall]

On Fri, 11 Mar 2022, Chris Jones wrote:

> MacPorts is not (just) 'a simple package manager'. Yes, it performs this 
> function, but first and foremost (and long before we even had binary 
> tarballs to distribute as a 'package mnager') it is a system for 
> building packages and their dependencies. To build something you require 
> a compiler. Many ports will build fine with just the Apple CLT package, 
> but some indeed require the full Xcode installation in order to be built 
> (and Xcode also is not just an IDE, but is also a command line build 
> system).

I couldn't have put it better myself; the fact that some packages 
(contributed to MacPorts) require Xcode is hardly MacPorts' fault.

I dips me lid to the MP maintainers for what is obviously a thankless job.

-- Dave

Re: code signing and the future of MacPorts

[Gerben Wierda via macports-users]

Additionally, I was thinking that the binary downloads of ports might be 
codesigned. That would prevent people from all having to buy a certificate 
themselves (and self-signed is not really an option, these are generally 
ignored, maybe not if you mark them as trusted). You can of course also create 
your own PKI and add its root cert as trusted in your own systems. There are a 
few avenues here.

Gerben Wierda (LinkedIn )
R IT Strategy  (main site)
Book: Chess and the Art of Enterprise Architecture 
Book: Mastering ArchiMate 

> On 11 Mar 2022, at 15:16, Gerben Wierda via macports-dev 
>  wrote:
> 
> I’ve recently moved from macOS Mojave with MacPorts to macOS Monterey with 
> MacPorts
> 
> I’ve had serious trouble with the application level firewall 
> (alf/socketfilterfw). I now suspect that one reason is that Apple is getting 
> stricter and stricter about only allowing binaries that have been code 
> signed. This might play more and more havoc with using open source e,g. via 
> MacPorts.
> 
> For instance, at this point, I cannot turn on socketfilterfw because it 
> blocks (in weird ways sometimes) my mail server. Even if I allow a certain 
> binary to run, socketfilterfw will report error like the “-67062’ error, 
> which stands for
> 
> % security error -67062
> Error: 0xFFFEFA0A -67062 code object is not signed at all
> 
> I’ve seen the socketfilterfw either block or not block in that situation. 
> There is  not discernible method. It seems macOS becomes more and more 
> unreliable when faced with unsigned apps, which is something that is the 
> default when using open source installs.
> 
> Apple itself signs everything. Even simple command line executables now have 
> an embedded signature:
> 
> gerben@hermione Downloads % codesign -v -d /bin/echo
> Executable=/bin/echo
> Identifier=com.apple.echo
> Format=Mach-O universal (x86_64 arm64e)
> CodeDirectory v=20400 size=583 flags=0x0(none) hashes=13+2 location=embedded
> Platform identifier=13
> Signature size=4442
> Signed Time=18 Dec 2021 at 18 December 01:20:02
> Info.plist=not bound
> TeamIdentifier=not set
> Sealed Resources=none
> Internal requirements count=1 size=64
> 
> There are more and more parts of macOS where the security screws are being 
> tightened more and more and code signing is a key element. 
> 
> I am therefore wondering if it will become necessary to add code signing to 
> the MacPorts install process, to support it in some way.
> 
> Gerben Wierda (LinkedIn )
> R IT Strategy  (main site)
> Book: Chess and the Art of Enterprise Architecture 
> 
> Book: Mastering ArchiMate 
> 

code signing and the future of MacPorts

[Gerben Wierda via macports-users]

I’ve recently moved from macOS Mojave with MacPorts to macOS Monterey with 
MacPorts

I’ve had serious trouble with the application level firewall 
(alf/socketfilterfw). I now suspect that one reason is that Apple is getting 
stricter and stricter about only allowing binaries that have been code signed. 
This might play more and more havoc with using open source e,g. via MacPorts.

For instance, at this point, I cannot turn on socketfilterfw because it blocks 
(in weird ways sometimes) my mail server. Even if I allow a certain binary to 
run, socketfilterfw will report error like the “-67062’ error, which stands for

% security error -67062
Error: 0xFFFEFA0A -67062 code object is not signed at all

I’ve seen the socketfilterfw either block or not block in that situation. There 
is  not discernible method. It seems macOS becomes more and more unreliable 
when faced with unsigned apps, which is something that is the default when 
using open source installs.

Apple itself signs everything. Even simple command line executables now have an 
embedded signature:

gerben@hermione Downloads % codesign -v -d /bin/echo
Executable=/bin/echo
Identifier=com.apple.echo
Format=Mach-O universal (x86_64 arm64e)
CodeDirectory v=20400 size=583 flags=0x0(none) hashes=13+2 location=embedded
Platform identifier=13
Signature size=4442
Signed Time=18 Dec 2021 at 18 December 01:20:02
Info.plist=not bound
TeamIdentifier=not set
Sealed Resources=none
Internal requirements count=1 size=64

There are more and more parts of macOS where the security screws are being 
tightened more and more and code signing is a key element. 

I am therefore wondering if it will become necessary to add code signing to the 
MacPorts install process, to support it in some way.

Gerben Wierda (LinkedIn )
R IT Strategy  (main site)
Book: Chess and the Art of Enterprise Architecture 
Book: Mastering ArchiMate 

Re: port diagnose and xcode

[Chris Jones]

On 11/03/2022 8:02 am, Michele Venturi wrote:

What is wrong is that a simple package manager
requires an entire multigigabyte professional IDE;
I have even taken the time to talk to them about it
and file a bug about it,but they clearly don't care...
It's surely not a new issue,it's like that by design...



MacPorts is not (just) 'a simple package manager'. Yes, it performs this 
function, but first and foremost (and long before we even had binary 
tarballs to distribute as a 'package mnager') it is a system for 
building packages and their dependencies. To build something you require 
a compiler. Many ports will build fine with just the Apple CLT package, 
but some indeed require the full Xcode installation in order to be built 
(and Xcode also is not just an IDE, but is also a command line build 
system).


So yes, if you want to put it in those terms requiring Xcode/CLT is 'by 
design'.




Il ven 11 mar 2022, 01:40 James Secan > ha scritto:


In working my way through my recent “phantom ports” issue I ran the
command “port diagnose” and was more than a bit surprised by the
output line:

Error: currently installed version of Xcode, none, is not supported
by MacPorts.

followed by a list of the version supported under my version of
macOS (El Capitan, in this case).  Where is port getting this
information?  I have Xcode 8.2.0 installed, and none of my attempts
to install ports have run into any trouble related to Xcode not
being installed.  I ran "pkgutil -v
--pkg-info=com.apple.pkg.CLTools_Executables” which shows that I
have 8.2.0 installed, and the appropriate MacOSX.sdk files are in
/Library/Developer/CommandLineTools/SDKs.  I also tried this on my
test Catalina system, with the same result.

Is something wrong with my ports setup?

Jim
3222 NE 89th St
Seattle, WA 98115
(206) 430-0109

 > On Mar 10, 2022, at 12:34 AM, Ryan Schmidt
mailto:ryandes...@macports.org>> wrote:
 >
 > On Mar 9, 2022, at 17:13, James Secan wrote:
 >>
 >> when I run "port upgrade installed -u outdated”
 >
 > This command doesn't make a great deal of sense. You're asking
MacPorts to upgrade the "installed" ports (which includes those
those that are outdated and those that aren't) and also the
"outdated" ports (those that are outdated). It would be simpler and
more efficient to just run "sudo port -u upgrade outdated".
Single-dash/single-letter flags like "-u" go after "port" and before
the action (the action in this case being "upgrade").
 >
 > For completeness, "-u" means "uninstall inactive ports"; if you
want to keep inactive ports, for example as a safeguard so that you
could return to them in case something is wrong with the new
version, then don't use "-u". When you eventually run "sudo port
reclaim", that will get rid of the inactive versions.
 >
 > MacPorts reminds to run "sudo port reclaim" if you have not done
so in a few weeks, unless you have configured MacPorts not to remind
you.

Re: port diagnose and xcode

[Michele Venturi]

What is wrong is that a simple package manager
requires an entire multigigabyte professional IDE;
I have even taken the time to talk to them about it
and file a bug about it,but they clearly don't care...
It's surely not a new issue,it's like that by design...

Il ven 11 mar 2022, 01:40 James Secan  ha scritto:

> In working my way through my recent “phantom ports” issue I ran the
> command “port diagnose” and was more than a bit surprised by the output
> line:
>
> Error: currently installed version of Xcode, none, is not supported by
> MacPorts.
>
> followed by a list of the version supported under my version of macOS (El
> Capitan, in this case).  Where is port getting this information?  I have
> Xcode 8.2.0 installed, and none of my attempts to install ports have run
> into any trouble related to Xcode not being installed.  I ran "pkgutil -v
> --pkg-info=com.apple.pkg.CLTools_Executables” which shows that I have 8.2.0
> installed, and the appropriate MacOSX.sdk files are in
> /Library/Developer/CommandLineTools/SDKs.  I also tried this on my test
> Catalina system, with the same result.
>
> Is something wrong with my ports setup?
>
> Jim
> 3222 NE 89th St
> Seattle, WA 98115
> (206) 430-0109
>
> > On Mar 10, 2022, at 12:34 AM, Ryan Schmidt 
> wrote:
> >
> > On Mar 9, 2022, at 17:13, James Secan wrote:
> >>
> >> when I run "port upgrade installed -u outdated”
> >
> > This command doesn't make a great deal of sense. You're asking MacPorts
> to upgrade the "installed" ports (which includes those those that are
> outdated and those that aren't) and also the "outdated" ports (those that
> are outdated). It would be simpler and more efficient to just run "sudo
> port -u upgrade outdated". Single-dash/single-letter flags like "-u" go
> after "port" and before the action (the action in this case being
> "upgrade").
> >
> > For completeness, "-u" means "uninstall inactive ports"; if you want to
> keep inactive ports, for example as a safeguard so that you could return to
> them in case something is wrong with the new version, then don't use "-u".
> When you eventually run "sudo port reclaim", that will get rid of the
> inactive versions.
> >
> > MacPorts reminds to run "sudo port reclaim" if you have not done so in a
> few weeks, unless you have configured MacPorts not to remind you.
>
>