Re: Login shell

2020-05-10 Thread Ken Cunningham
> I'd be interested in any experience running Linux software directly on macOS, 
> without installing Linux.

your best bet is to see what you'd like, and see if someone has made it work on 
macports; there is a lot, really. the very latest Apache2 runs on everything 
back to Tiger PPC for example.

On the wildly-experimental front, a maybe-might-run-something compatability 
layer was just added to macports. The idea is to run ELF linux binaries 
directly on macOS. You are certain to run into some issues, but look into noah:

port info noah

K

Re: Login shell

2020-05-10 Thread Dmitri Zaitsev
Is this the post you are referring to?
https://lists.macports.org/pipermail/macports-users/2020-April/048223.html

When I tried Ubuntu on Mac Pro, I couldn't get any sound and trying to
look for help online it felt like another rabbit hole to jump in :(
Old problems solved, new ones created :(

I was reading this and thought it referred to using
no-mac-era-software from within macOS:
>> > I don’t use any MacOS-era software to access anything outside the network.

I'd be interested in any experience running Linux software directly on
macOS, without installing Linux.


On Sun, May 10, 2020 at 12:54 PM Ken Cunningham
 wrote:
>
> If you look back a few days earlier in this list, you'll see my experiences 
> in installing Ubuntu on older MacOS hardware -- I just went through the 
> process and documented it there -- and there are various resources on the web 
> that weren't too hard to find. I'm typing this on Ubuntu running on a MacBook 
> 2,1 now.
>
>
> It has some nice features. But there are warts.
>
>
> Ken
>
>
>
>
> On 2020-05-09 10:05 p.m., Dmitri Zaitsev wrote:
>
> I would be very interested to learn how to avoid the insecure MacOS software 
> replacing it with that from Linux land. Any good source to read about it?
>
> On Sun, May 10, 2020, 07:47 Daniel J. Luke  wrote:
>>
>> On May 7, 2020, at 3:34 PM, Ken Cunningham  
>> wrote:
>> >> there are large closed-source surface areas that you aren't going to be 
>> >> able to keep updated.
>> >
>> > You have said that before, and I listened, but:
>> >
>> > all my systems live behind a firewall, and none are exposed to the open 
>> > web.
>> > I don’t use any MacOS-era software to access anything outside the network. 
>> > Only, really, MacPorts stuff (all with up-to-date security) and TenFourFox 
>> > (also built with MacPorts stuff, also with all up to date security).
>>
>> ... and they're probably all linked with versions of Libsystem that don't 
>> have the most recent patches from Apple (you could probably be backporting 
>> them, but I doubt you're doing that :) ).
>>
>> > I just don’t see the vulnerability, TBH.
>> >
>> > If you know of any, please give me an example. I don’t want to be stupid 
>> > about things.
>>
>> It's risky - the majority of bugs that Apple releases security patches for 
>> are in components that exist in previous Mac OS versions. Maybe those 
>> versions don't have those problems (but they probably do). Maybe no one is 
>> exploiting them.
>>
>> If you are firewalling and monitoring both inbound and outbound traffic, 
>> maybe you've set things up so that you can run a vulnerable system safely. 
>> Most people aren't capable of doing that. These kinds of things are hard to 
>> do well - if you've got a strong perimeter, but vulnerable systems inside - 
>> it just takes one problem with your perimeter security and an attacker has 
>> access to everything you thought was secured by your perimeter security.
>>
>> > The time daemon, maybe? I heard there was something about that daemon,
>>
>> yeah, it's had a bunch of problems.
>>
>> > but it just checks Apple’s time server.
>>
>> how do you know? (hint: ntp uses udp and also bgp-interdomain routing is 
>> still largely insecure).
>>
>> > I could replace that too, I guess...
>>
>> At that point, if you're not using any MacOS software - why are you running 
>> Mac OS at all? That hardware can run an OS that's still getting security 
>> patches and run all of the unix-y software that's in Macports without the 
>> risk.
>>
>> (Of course, Mac OS UI and hardware drivers are generally better, so I 
>> understand there may be reasons why people might want to do this - but I 
>> think it's too easy to overlook the potential downside).
>>
>> [This is probably off-topic for macports, so I'll refrain from typing more]
>> --
>> Daniel J. Luke
>>


-- 
Dmitri Zaitsev
School of Mathematics
Trinity College Dublin

WWW:  http://www.maths.tcd.ie/~zaitsev/


Re: Login shell

2020-05-09 Thread Ken Cunningham
If you look back a few days earlier in this list, you'll see my 
experiences in installing Ubuntu on older MacOS hardware -- I just went 
through the process and documented it there -- and there are various 
resources on the web that weren't too hard to find. I'm typing this on 
Ubuntu running on a MacBook 2,1 now.



It has some nice features. But there are warts.


Ken




On 2020-05-09 10:05 p.m., Dmitri Zaitsev wrote:
I would be very interested to learn how to avoid the insecure MacOS 
software replacing it with that from Linux land. Any good source to 
read about it?


On Sun, May 10, 2020, 07:47 Daniel J. Luke > wrote:


On May 7, 2020, at 3:34 PM, Ken Cunningham
mailto:ken.cunningham.web...@gmail.com>> wrote:
>> there are large closed-source surface areas that you aren't
going to be able to keep updated.
>
> You have said that before, and I listened, but:
>
> all my systems live behind a firewall, and none are exposed to
the open web.
> I don’t use any MacOS-era software to access anything outside
the network. Only, really, MacPorts stuff (all with up-to-date
security) and TenFourFox (also built with MacPorts stuff, also
with all up to date security).

... and they're probably all linked with versions of Libsystem
that don't have the most recent patches from Apple (you could
probably be backporting them, but I doubt you're doing that :) ).

> I just don’t see the vulnerability, TBH.
>
> If you know of any, please give me an example. I don’t want to
be stupid about things.

It's risky - the majority of bugs that Apple releases security
patches for are in components that exist in previous Mac OS
versions. Maybe those versions don't have those problems (but they
probably do). Maybe no one is exploiting them.

If you are firewalling and monitoring both inbound and outbound
traffic, maybe you've set things up so that you can run a
vulnerable system safely. Most people aren't capable of doing
that. These kinds of things are hard to do well - if you've got a
strong perimeter, but vulnerable systems inside - it just takes
one problem with your perimeter security and an attacker has
access to everything you thought was secured by your perimeter
security.

> The time daemon, maybe? I heard there was something about that
daemon,

yeah, it's had a bunch of problems.

> but it just checks Apple’s time server.

how do you know? (hint: ntp uses udp and also bgp-interdomain
routing is still largely insecure).

> I could replace that too, I guess...

At that point, if you're not using any MacOS software - why are
you running Mac OS at all? That hardware can run an OS that's
still getting security patches and run all of the unix-y software
that's in Macports without the risk.

(Of course, Mac OS UI and hardware drivers are generally better,
so I understand there may be reasons why people might want to do
this - but I think it's too easy to overlook the potential downside).

[This is probably off-topic for macports, so I'll refrain from
typing more]
-- 
Daniel J. Luke




Re: Login shell

2020-05-09 Thread Dmitri Zaitsev
I would be very interested to learn how to avoid the insecure MacOS
software replacing it with that from Linux land. Any good source to read
about it?

On Sun, May 10, 2020, 07:47 Daniel J. Luke  wrote:

> On May 7, 2020, at 3:34 PM, Ken Cunningham <
> ken.cunningham.web...@gmail.com> wrote:
> >> there are large closed-source surface areas that you aren't going to be
> able to keep updated.
> >
> > You have said that before, and I listened, but:
> >
> > all my systems live behind a firewall, and none are exposed to the open
> web.
> > I don’t use any MacOS-era software to access anything outside the
> network. Only, really, MacPorts stuff (all with up-to-date security) and
> TenFourFox (also built with MacPorts stuff, also with all up to date
> security).
>
> ... and they're probably all linked with versions of Libsystem that don't
> have the most recent patches from Apple (you could probably be backporting
> them, but I doubt you're doing that :) ).
>
> > I just don’t see the vulnerability, TBH.
> >
> > If you know of any, please give me an example. I don’t want to be stupid
> about things.
>
> It's risky - the majority of bugs that Apple releases security patches for
> are in components that exist in previous Mac OS versions. Maybe those
> versions don't have those problems (but they probably do). Maybe no one is
> exploiting them.
>
> If you are firewalling and monitoring both inbound and outbound traffic,
> maybe you've set things up so that you can run a vulnerable system safely.
> Most people aren't capable of doing that. These kinds of things are hard to
> do well - if you've got a strong perimeter, but vulnerable systems inside -
> it just takes one problem with your perimeter security and an attacker has
> access to everything you thought was secured by your perimeter security.
>
> > The time daemon, maybe? I heard there was something about that daemon,
>
> yeah, it's had a bunch of problems.
>
> > but it just checks Apple’s time server.
>
> how do you know? (hint: ntp uses udp and also bgp-interdomain routing is
> still largely insecure).
>
> > I could replace that too, I guess...
>
> At that point, if you're not using any MacOS software - why are you
> running Mac OS at all? That hardware can run an OS that's still getting
> security patches and run all of the unix-y software that's in Macports
> without the risk.
>
> (Of course, Mac OS UI and hardware drivers are generally better, so I
> understand there may be reasons why people might want to do this - but I
> think it's too easy to overlook the potential downside).
>
> [This is probably off-topic for macports, so I'll refrain from typing more]
> --
> Daniel J. Luke
>
>


Re: Login shell

2020-05-09 Thread Daniel J. Luke
On May 7, 2020, at 3:34 PM, Ken Cunningham  
wrote:
>> there are large closed-source surface areas that you aren't going to be able 
>> to keep updated.
> 
> You have said that before, and I listened, but: 
> 
> all my systems live behind a firewall, and none are exposed to the open web.
> I don’t use any MacOS-era software to access anything outside the network. 
> Only, really, MacPorts stuff (all with up-to-date security) and TenFourFox 
> (also built with MacPorts stuff, also with all up to date security).

... and they're probably all linked with versions of Libsystem that don't have 
the most recent patches from Apple (you could probably be backporting them, but 
I doubt you're doing that :) ).

> I just don’t see the vulnerability, TBH.
> 
> If you know of any, please give me an example. I don’t want to be stupid 
> about things.

It's risky - the majority of bugs that Apple releases security patches for are 
in components that exist in previous Mac OS versions. Maybe those versions 
don't have those problems (but they probably do). Maybe no one is exploiting 
them.

If you are firewalling and monitoring both inbound and outbound traffic, maybe 
you've set things up so that you can run a vulnerable system safely. Most 
people aren't capable of doing that. These kinds of things are hard to do well 
- if you've got a strong perimeter, but vulnerable systems inside - it just 
takes one problem with your perimeter security and an attacker has access to 
everything you thought was secured by your perimeter security.

> The time daemon, maybe? I heard there was something about that daemon,

yeah, it's had a bunch of problems.

> but it just checks Apple’s time server.

how do you know? (hint: ntp uses udp and also bgp-interdomain routing is still 
largely insecure).

> I could replace that too, I guess...

At that point, if you're not using any MacOS software - why are you running Mac 
OS at all? That hardware can run an OS that's still getting security patches 
and run all of the unix-y software that's in Macports without the risk.

(Of course, Mac OS UI and hardware drivers are generally better, so I 
understand there may be reasons why people might want to do this - but I think 
it's too easy to overlook the potential downside).

[This is probably off-topic for macports, so I'll refrain from typing more]
-- 
Daniel J. Luke



Re: Login shell

2020-05-07 Thread raf
Richard L. Hamilton wrote:

> Or see https://support.apple.com/kb/HT208050 
>  which describes the new behavior, and 
> how to use Users and Groups to change the default shell, or how to use 
> Terminal preferences to use bash by default from Terminal  (only, i.e. not if 
> ssh'd in) without changing the default shell. It also mentions a few other 
> things,, including how to silence the annoying warning  (which they hardcoded 
> into bash itself, so you can't find some startup file to silence it):
> 
>  To silence this warning, you can add this command to ~/.bash_profile or 
> ~/.profile:
> export BASH_SILENCE_DEPRECATION_WARNING=1
> 
> I wondered why they made the change, so I googled and found 
> https://pawelgrzybek.com/apple-changed-the-default-shell-from-bash-to-zsh-so-did-i/
>  
> 

Luckily, I've been using zsh since about 1990 so I wouldn't notice.
But I can't upgrade to Catalina anyway, or I'd lose a precious 32bit
program.

cheers,
raf



Re: Login shell

2020-05-07 Thread Ken Cunningham
> there are large closed-source surface areas that you aren't going to be able 
> to keep updated.

You have said that before, and I listened, but: 

all my systems live behind a firewall, and none are exposed to the open web.
I don’t use any MacOS-era software to access anything outside the network. 
Only, really, MacPorts stuff (all with up-to-date security) and TenFourFox 
(also built with MacPorts stuff, also with all up to date security).

I just don’t see the vulnerability, TBH.

If you know of any, please give me an example. I don’t want to be stupid about 
things.

The time daemon, maybe? I heard there was something about that daemon, but it 
just checks Apple’s time server. I could replace that too, I guess...


Sincerely curious,

Ken

Re: Login shell

2020-05-07 Thread Daniel J. Luke
On May 7, 2020, at 2:48 PM, Bill Cole 
 wrote:
> That looks like my ugly hack. I came up with it shortly after the disclosure 
> of the "ShellShock" vulnerability.
> 
> The reason to do this when replacing a login shell or (most importantly) the 
> system shell at /bin/sh is that you do not want either of those to be 
> breakable by modification of a shared library installed by MacPorts.

alternatively, at the time I believe I downloaded the source from Apple, 
applied the upstream patch, and replaced the system /bin/sh with the result.

> The primary reason that one should replace /bin/{bash,sh} with a newer 
> version on older versions of MacOS X is ShellShock.

People who are running older versions of Mac OS X have chosen not to care about 
vulnerabilities - since they're no longer getting security updates from Apple. 
While it's maybe possible to patch/replace some of the parts of the system - 
there are large closed-source surface areas that you aren't going to be able to 
keep updated.

-- 
Daniel J. Luke



Re: Login shell

2020-05-07 Thread Bill Cole

On 7 May 2020, at 12:45, Ken Cunningham wrote:

I replace the system bash on older systems with the MP version, esp on 
Tiger.


There was a nice trick presented on the mailing list a year or two ago 
by someone to use static libs to make it less fragile, so I use that:


<https://github.com/kencu/myports/tree/master/shells/bash>


That looks like my ugly hack. I came up with it shortly after the 
disclosure of the "ShellShock" vulnerability.


The reason to do this when replacing a login shell or (most importantly) 
the system shell at /bin/sh is that you do not want either of those to 
be breakable by modification of a shared library installed by MacPorts.


The primary reason that one should replace /bin/{bash,sh} with a newer 
version on older versions of MacOS X is ShellShock.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)


Re: Login shell

2020-05-07 Thread Ken Cunningham
I replace the system bash on older systems with the MP version, esp on Tiger.

There was a nice trick presented on the mailing list a year or two ago by 
someone to use static libs to make it less fragile, so I use that:



Re: Login shell

2020-05-07 Thread Richard L. Hamilton
Or see https://support.apple.com/kb/HT208050 
<https://support.apple.com/kb/HT208050> which describes the new behavior, and 
how to use Users and Groups to change the default shell, or how to use Terminal 
preferences to use bash by default from Terminal  (only, i.e. not if ssh'd in) 
without changing the default shell. It also mentions a few other things,, 
including how to silence the annoying warning  (which they hardcoded into bash 
itself, so you can't find some startup file to silence it):

 To silence this warning, you can add this command to ~/.bash_profile or 
~/.profile:
export BASH_SILENCE_DEPRECATION_WARNING=1

I wondered why they made the change, so I googled and found 
https://pawelgrzybek.com/apple-changed-the-default-shell-from-bash-to-zsh-so-did-i/
 
<https://pawelgrzybek.com/apple-changed-the-default-shell-from-bash-to-zsh-so-did-i/>

> On May 7, 2020, at 11:40, Daniel J. Luke  wrote:
> 
> On May 7, 2020, at 11:38 AM, Christoph Kukulies  wrote:
>> 
>> I don’t know if that belongs into macports, but I believe a lot of problems 
>> (I currently have) with PATHs may be, that Catalina (?) changed the login 
>> shell from sh (bash) to zsh (or am I wrong with this)?
>> 
>> Where do I change the users’  lofin shell. Unixwise I would say in 
>> /etc/passwd, but I don’t find any (my) username there.
> 
> use the 'chsh' command to change your shell.
> 
>> For instance my anaconda3 installation was totally spoiled after updating to 
>> Catalina.
>> 
>> For the fun of it I started bash, did a . .bash_profile and started 
>> 
>> conda update —prefix /opt/anaconda3  anaconda
>> 
>> and lo and behold, I received a smooth update in that window. 
>> 
>> Would the world be better for me if I go back to bash login shell? And why 
>> did Catalina cause such a mess?
> 
> For my computer, it didn't change my shell - but prints a message telling me 
> that I should. I just installed bash from macports and have it set as my 
> shell :)
> 
> -- 
> Daniel J. Luke
> 
> 



Re: Login shell

2020-05-07 Thread Daniel J. Luke
On May 7, 2020, at 11:38 AM, Christoph Kukulies  wrote:
> 
> I don’t know if that belongs into macports, but I believe a lot of problems 
> (I currently have) with PATHs may be, that Catalina (?) changed the login 
> shell from sh (bash) to zsh (or am I wrong with this)?
> 
> Where do I change the users’  lofin shell. Unixwise I would say in 
> /etc/passwd, but I don’t find any (my) username there.

use the 'chsh' command to change your shell.

> For instance my anaconda3 installation was totally spoiled after updating to 
> Catalina.
> 
> For the fun of it I started bash, did a . .bash_profile and started 
> 
> conda update —prefix /opt/anaconda3  anaconda
> 
> and lo and behold, I received a smooth update in that window. 
> 
> Would the world be better for me if I go back to bash login shell? And why 
> did Catalina cause such a mess?

For my computer, it didn't change my shell - but prints a message telling me 
that I should. I just installed bash from macports and have it set as my shell 
:)

-- 
Daniel J. Luke



Login shell

2020-05-07 Thread Christoph Kukulies
I don’t know if that belongs into macports, but I believe a lot of problems (I 
currently have) with PATHs may be, that Catalina (?) changed the login shell 
from sh (bash) to zsh (or am I wrong with this)?

Where do I change the users’  lofin shell. Unixwise I would say in /etc/passwd, 
but I don’t find any (my) username there.

For instance my anaconda3 installation was totally spoiled after updating to 
Catalina.

For the fun of it I started bash, did a . .bash_profile and started 

conda update —prefix /opt/anaconda3  anaconda

and lo and behold, I received a smooth update in that window. 

Would the world be better for me if I go back to bash login shell? And why did 
Catalina cause such a mess?

—
Christoph