I would make your fix a configure option that is off by default. It is silly 
that Apple makes you use sudo to tell it that a compiled code SHOULD NOT accept 
outside connections but they have it all bundled together without enough 
thought for developers.

  Barry


> On Aug 31, 2020, at 4:14 AM, Hapla Vaclav <vaclav.ha...@erdw.ethz.ch> wrote:
> 
> 
>> On 29 Aug 2020, at 02:03, Hapla Vaclav <vaclav.ha...@erdw.ethz.ch> wrote:
>> 
>> 
>> 
>>> On 28 Aug 2020, at 22:47, Jed Brown <j...@jedbrown.org> wrote:
>>> 
>>> "Hapla  Vaclav" <vaclav.ha...@erdw.ethz.ch> writes:
>>> 
>>>> On MacOS, maybe you also have lots of firewall popups 
>>>> appearing/disappearing when running tests like
>>>> Do you want the application "ex29" to accept incoming network connections?
>>> 
>>> Is there a way to express that the application does not need (should not 
>>> accept) incoming connections?
>> 
>> Oh yes, hadn't thought about before, but it's surely better to _block_ the 
>> incoming connections - feels safer for a user at least.
>> 
>> But the way is the same, requiring sudo:
>> 
>> sudo /usr/libexec/ApplicationFirewall/socketfilterfw --add 
>> $PETSC_DIR/$PETSC_ARCH/tests/dm/impls/plex/tests/ex9
>> sudo /usr/libexec/ApplicationFirewall/socketfilterfw --block 
>> $PETSC_DIR/$PETSC_ARCH/tests/dm/impls/plex/tests/ex9
>> 
>> Funny enough, these commands don't fail without sudo but they have no effect.
>> 
>>> 
>>> Normalizing sudo during build/testing seems really bad.
>> 
>> I agree. It shouldn't be a normal part of the makefile. That's why I have 
>> been hesitant to create a MR. I think we could
>> 1. just add an FAQ entry - but the patch can become out-of-date pretty 
>> quickly, and instructions without a patch are gonna be tedious
>> 2. activate this part conditionally, requiring a user's action such as 
>> passing a very special variable to makefile
>> 3. put it into a separate makefile and add a commented out include into 
>> gmakefile.test, so that the user has to explicitly uncomment the inclusion - 
>> or something like that
>> 4. something else?
> 
> Jed, Barry, thoughts here?
> 
> Thanks,
> Vaclav
> 
>> 
>> Vaclav
> 

Reply via email to