Re: [gtk-osx-devel] Problems with gtk-osx-setup.sh - M1

[john]

Please remember to copy the list on all replies.

Of course one can't rely on something being in /usr/local, but that misses the 
point: If you install something in /usr/local the compiler is going to find it 
unless there's another instance in the command line search list (-I and -L). 
Worse, /usr/local/bin is on the default path. That's why Homebrew-on-Intel's 
default of creating symlinks there changes Homebrew from a convenience to a 
serious vulnerability. Poorly controlled package managers like that are a rich 
opportunity for bad guys, e.g. 
https://arstechnica.com/information-technology/2021/11/malware-downloaded-from-pypi-41000-times-was-surprisingly-stealthy/.

The sandbox-exec article is interesting, though I'm skeptical that Apple is 
really using it for much: It's built on the Application Sandbox feature that's 
required for App Store and Notarized apps. *That* part of it is obviously not 
going away, but it looks like Apple wants us to use Launch Services for 
accessing it, not the original sandbox_init(). One could set up a jhbuild 
environment that way, but it's probably no less complicated that the chroot 
jail method that most Unix developers already know how to do and that Apple 
can't disable in the future.

Regards,
John Ralls


> On Feb 18, 2022, at 8:13 AM, Spock  wrote:
> 
> You’d be surprised just how much 1980’s (and earlier) code is still running - 
> hence my now-and-again use of 3270 ...
> In my case, I do talks for kids on “how things used to be” and so keeping 
> roughly familiar with MVS and some other systems is a important to me.
> 
> You will see that I used the English passive-aggressive “friendly” when 
> talking about CMake - of course, it’s anything but that!
> 
> On /usr/local though, no application being built for distribution should ever 
> rely on anything in that subtree - unless the application developer puts the 
> code there as part of an installation it can’t rely on it being there. Such 
> is life on unix … I can’t count the number of times I have seen people 
> accidentally link to something in /usr/local only to find that their 
> application won’t load or breaks in some horrible way on a different machine.
> 
> On the “build in a container” front, I totally agree - though to build on 
> MacOS you don’t want a docker container. Docker would give you a linux 
> environment … As an aside, many like podman as a docker alternative, but that 
> is best installed using, er, *cough* *cough*, homebrew! 
> 
> There’s some discussion around how to have a sandboxed macOS environment 
> running inside MacOS. See https://macoscontainers.org 
>  for example. This is an interesting article, 
> but probably not much use for Gtk-OSX - 
> https://www.karltarvas.com/2020/10/25/macos-app-sandboxing-via-sandbox-exec.html
>  
> 
> 
> 
> Best
> Paul
> 
>> On 18 Feb 2022, at 04:54, john > > wrote:
>> 
>> 3270 is still a  thing? Scary.
>> 
>> CMake's bug isn't really that recent, the fink and MacPorts inclusion goes 
>> back more than 10 years, and homebrew-on-intel uses /usr/local that's on the 
>> hard-coded defaults built into the kernel and every Unix compiler I've met. 
>> This is also the first time I've heard anyone claim that Cmake is friendly!
>> 
>> Meson's pretty nice. The only wart I've run up against is that fallback 
>> feature, which is fine if your environment happens to fit the fallback's 
>> settings but is otherwise a PITA. A lot of the GNOME projects have migrated 
>> their builds to it.
>> 
>> I'll think a bit on how to word the paragraph in Building Gtk-OSX. I think 
>> the ultimate solution is Docker-style containers but since Docker is very 
>> much not Free I'm reluctant to promote it. Flatpak would be an obvious GNOME 
>> alternative but AFAIK it doesn't play well with macOS and I don't have any 
>> bandwidth available to do anything about that.
>> 
>> Regards,
>> John Ralls
>> 
>> 
>>> On Feb 17, 2022, at 10:46 AM, Spock >> > wrote:
>>> 
>>> I guess it all depends on whether you use your Mac exclusively for 
>>> developing gtk apps or not. Certainly on my Macs, I have need of a number 
>>> of tools that are out of-date in the Apple supplied versions and so use 
>>> homebrew for more recent versions. In the possibly most simple use case, I 
>>> use htop to monitor system performance - Apple does not supply it, so I use 
>>> homebrew … I use meld, supplied again by homebrew … I also develop a number 
>>> of different projects where a unix-like set of tools are required. If I 
>>> want to develop linux stuff for linux, I have machines or VMs for that ...
>>> 
>>> Oh, I also use applications such as c3270 (part of x3270) for accessing 
>>> some legacy systems … I get them from homebrew ..
>>> 
>>> So it goes on. The gtk-osx world and the rest-of-the-world should really 
>>> find a way to 

Re: [gtk-osx-devel] Problems with gtk-osx-setup.sh - M1

[Spock]

Sorry about not doing the reply-all - many decades of trying not to do that 
accidentally …

Agree on /usr/local - we are making the same point but two different ways. On 
any unix type system any developer simply has to take care to avoid problems 
with /user/local - “ignore at your peril” if you like … Certainly the 
professional projects I have led and/or been involved with have always taken 
serious steps to obviate these problems. Most of the time a chroot gaol was the 
answer - hence my fondness for containers which are a more full-fat version of 
the same thing. Interestingly even “dedicated build servers” ended up becoming 
infected with cruft … leading back to container-like build systems.

Agreed on sandbox-exec - I mentioned it just so you could see what some are 
thinking about. There are some challenges for gaols on macOS in recent versions 
given the development of SIP - where system dyld’s are not present in the user 
visible filesystem.


Best
Paul

> On 18 Feb 2022, at 17:31, john  wrote:
> 
> Please remember to copy the list on all replies.
> 
> Of course one can't rely on something being in /usr/local, but that misses 
> the point: If you install something in /usr/local the compiler is going to 
> find it unless there's another instance in the command line search list (-I 
> and -L). Worse, /usr/local/bin is on the default path. That's why 
> Homebrew-on-Intel's default of creating symlinks there changes Homebrew from 
> a convenience to a serious vulnerability. Poorly controlled package managers 
> like that are a rich opportunity for bad guys, e.g. 
> https://arstechnica.com/information-technology/2021/11/malware-downloaded-from-pypi-41000-times-was-surprisingly-stealthy/
>  
> .
> 
> The sandbox-exec article is interesting, though I'm skeptical that Apple is 
> really using it for much: It's built on the Application Sandbox feature 
> that's required for App Store and Notarized apps. *That* part of it is 
> obviously not going away, but it looks like Apple wants us to use Launch 
> Services for accessing it, not the original sandbox_init(). One could set up 
> a jhbuild environment that way, but it's probably no less complicated that 
> the chroot jail method that most Unix developers already know how to do and 
> that Apple can't disable in the future.
> 
> Regards,
> John Ralls
> 
> 
>> On Feb 18, 2022, at 8:13 AM, Spock > > wrote:
>> 
>> You’d be surprised just how much 1980’s (and earlier) code is still running 
>> - hence my now-and-again use of 3270 ...
>> In my case, I do talks for kids on “how things used to be” and so keeping 
>> roughly familiar with MVS and some other systems is a important to me.
>> 
>> You will see that I used the English passive-aggressive “friendly” when 
>> talking about CMake - of course, it’s anything but that!
>> 
>> On /usr/local though, no application being built for distribution should 
>> ever rely on anything in that subtree - unless the application developer 
>> puts the code there as part of an installation it can’t rely on it being 
>> there. Such is life on unix … I can’t count the number of times I have seen 
>> people accidentally link to something in /usr/local only to find that their 
>> application won’t load or breaks in some horrible way on a different machine.
>> 
>> On the “build in a container” front, I totally agree - though to build on 
>> MacOS you don’t want a docker container. Docker would give you a linux 
>> environment … As an aside, many like podman as a docker alternative, but 
>> that is best installed using, er, *cough* *cough*, homebrew! 
>> 
>> There’s some discussion around how to have a sandboxed macOS environment 
>> running inside MacOS. See https://macoscontainers.org 
>>  for example. This is an interesting article, 
>> but probably not much use for Gtk-OSX - 
>> https://www.karltarvas.com/2020/10/25/macos-app-sandboxing-via-sandbox-exec.html
>>  
>> 
>> 
>> 
>> Best
>> Paul
>> 
>>> On 18 Feb 2022, at 04:54, john >> > wrote:
>>> 
>>> 3270 is still a  thing? Scary.
>>> 
>>> CMake's bug isn't really that recent, the fink and MacPorts inclusion goes 
>>> back more than 10 years, and homebrew-on-intel uses /usr/local that's on 
>>> the hard-coded defaults built into the kernel and every Unix compiler I've 
>>> met. This is also the first time I've heard anyone claim that Cmake is 
>>> friendly!
>>> 
>>> Meson's pretty nice. The only wart I've run up against is that fallback 
>>> feature, which is fine if your environment happens to fit the fallback's 
>>> settings but is otherwise a PITA. A lot of the GNOME projects have migrated 
>>> their builds to it.
>>> 
>>> I'll think a bit on how to word the paragraph in Building