Re: [Oorexx-devel] portable (usb) ooRexx 5.00

2018-11-21 Thread CV Bruce 
There are some minor changes to the code that would allow ooRexx to run, on Mac 
OS, from any folder it is copied to without recompiling.  There are some 
special library load paths that inform Mac OS of the relative location of 
shared libraries.  Because Mac OS by default searches some libraries that are 
specifically in the code for linux (like /usr/lib), a Mac OS version could 
replace that section of the code that searches those library load paths with 
the special relative paths.
This would also eliminate having to code any environmental variable pointing to 
the library path.

I forget which source file the code is in, but it is the one that performs the 
library loads.  I would have to look up the form of the relative path that you 
code, but it would be something that would be relative to the executable.

If you’re interested in making those changes, I would be happy to look it up 
again.

Bruce
> On Mar 30, 2018, at 11:24 AM, P.O. Jonsson  wrote:
> 
> Dear developers,
> 
> I think the discussion have gone off in another direction than the title 
> proposes (I have no opinion on that matter) but for what it is worth I just 
> now created an ooRexx installation that runs of a USB stick, with no use of 
> superuser powers whatsoever.
> 
> It is only for MAC but the idea is extremely simple and should be possible to 
> take to other platforms: During the CMake I redirected the installation to 
> /volumes/. After that the only thing I needed to do was to 
> amend the path.
> 
> Can be found here, instructions for use in the dmg image, just mount it and 
> read howto.txt. 
> 
> https://www.dropbox.com/sh/p66c7g01h4jz5ss/AAAZd_Q2yQddrTHagxPo_UiTa?dl=0 
> 
> 
> 
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se 
> 
> 
> 
> 
>> Am 30.03.2018 um 17:02 schrieb René Jansen > >:
>> 
>> Moritz,
>> 
>> After Gil’s talk I am also excited about ADDRESS WITH (and the fact that it 
>> has been taken up by Rick) so we might hold off the freeze for some time 
>> until we have all infrastructure and installers ready (and maybe have 
>> ADDRESS WITH). Maybe this gives us also time to look into the portable 
>> version again. I personally think this would be a great boost for takeup.
>> 
>> I remember you had a set of patches to turn the sockets of rxapi into pipes. 
>> I do not remember if this was windows-only or also included linux/macos.
>> 
>> The issues with rxapi:
>> 
>> - you must be authorized to run it on its port
>> - the firewall must allow access (cost me great headaches on Z, where the 
>> standard image for a Linux VM was very restrictive, and you got a timeout 
>> and no message)
>> - you must be authorized to start it, so that means a service on windows or 
>> some systemd / startup item
>> - it writes a PID file so whoever starts it, must be authorized to write 
>> there
>> 
>> Thing is, solutions must work for the three main platforms, that is the 
>> reason of my question.
>> 
>> best regards,
>> 
>> 
>> René
>> 
>> 
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org ! 
>> http://sdm.link/slashdot 
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net 
>> 
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! 
> http://sdm.link/slashdot___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] portable (usb) ooRexx 5.00

2018-11-21 Thread Rick McGuire 
Grrr, didn't get to the undo button in time...


On Wed, Nov 21, 2018 at 9:07 AM Rick McGuire  wrote:

> I have started doing a little research on this, and I see how to implement
> this on Windows, but I'm not sure the existing client/server set up will
> work with *ix named pipes. The rxapi process handles requests like this:
>
> Main thread binds to a port
>
do forever

> Main thread listens for an inbound connection, which will be a new process
> where rexx is being used.
> A new thread is created to handle requests from this session, terminating
> once the client process terminates.
>
end

On Windows, a server can have multiple active named pipe connections using
a common name. It does not appear that Linux has that capability. I have
seen some references to using AF_LOCAL (or AF_UNIX) sockets which bind
using a service name, which looks like a fairly easy replacement for what
we currently have. Windows, sadly, does not have AF_UNIX support except in
some updates of Windows 10, but the named pipe solution can be abstracted
to behave the same way.

Unless I'm missing something, how did you envision doing this with named
pipes? Links to relevant docs greatly appreciated!

Rick


>
>
> On Fri, Mar 30, 2018 at 2:10 PM Moritz Hoffmann 
> wrote:
>
>> The pipes-based version has one rxapi deamon per user. In fact, the pipe
>> file is owned and only accessible by the user that spawned the rxapi
>> daemon. That means another user has no way of accessing the pipe. I should
>> have some time tomorrow so I can see how much work it is for *nix, but I'd
>> need someone else to look at the Windows part (although the Windows doc
>> seems to be quite clear about named pipes, just have to get my development
>> environment up.)
>>
>> Moritz
>>
>> On Fri, Mar 30, 2018 at 6:47 PM, Rick McGuire 
>> wrote:
>>
>>> Does the pipes-based version have real user isolation? In other words,
>>> do you end up with one process per user? That would be a very good thing if
>>> we can get the real isolation. However, I think I share your opinion about
>>> trying to rush a replacement into 5.0.0. Historically, the rxapi daemon has
>>> been the source of a lot of problems whenever things have changed, so any
>>> replacement should get a lot of use and exposure before doing a roll out.
>>>
>>> Rick
>>>
>>> On Fri, Mar 30, 2018 at 12:40 PM, Moritz Hoffmann 
>>> wrote:
>>>
 Hi,
 yes, I was playing around with supporting pipes as another means of
 binding to the rxapi daemon. It was a rather simple change, the main effort
 was in extending/changing the communication abstraction classes not to
 assume they were socket-based. I had it running on Linux and I assume the
 same functionality would be available on MacOS, but I've no experience on
 how to use pipes in Windows. Quite sure they exist though!

 I'm not too sure we should include it in the 5.0.0 release. Firstly, it
 will require some testing and I'm sure it will have bugs at the beginning,
 just due to the fact that the pipe file needs to be stored somewhere and
 that might be different depending on the Linux distribution. Secondly, the
 rxapi daemon works fine at the moment.

 The only problem I see with the rxapi daemon is that it does not
 provide any isolation of users on the same host. The user id is passed as
 data in the messages so it's easy to patch ooRexx to use a different id
 instead. I guess we could call it a known and currently accepted
 vulnerability. Anyone who can connect to localhost can access the shared
 api daemon.

 If there's interest I could spin up the pipes-based version. Should
 take too long, just let me know.

 Moritz

 On Fri, Mar 30, 2018 at 5:02 PM, René Jansen 
 wrote:

> Moritz,
>
> After Gil’s talk I am also excited about ADDRESS WITH (and the fact
> that it has been taken up by Rick) so we might hold off the freeze for 
> some
> time until we have all infrastructure and installers ready (and maybe have
> ADDRESS WITH). Maybe this gives us also time to look into the portable
> version again. I personally think this would be a great boost for takeup.
>
> I remember you had a set of patches to turn the sockets of rxapi into
> pipes. I do not remember if this was windows-only or also included
> linux/macos.
>
> The issues with rxapi:
>
> - you must be authorized to run it on its port
> - the firewall must allow access (cost me great headaches on Z, where
> the standard image for a Linux VM was very restrictive, and you got a
> timeout and no message)
> - you must be authorized to start it, so that means a service on
> windows or some systemd / startup item
> - it writes a PID file so whoever starts it, must be authorized to
> write there
>
> Thing is, solutions must work for the three main platforms, that is
> the reason of my question.

Re: [Oorexx-devel] portable (usb) ooRexx 5.00

2018-11-21 Thread Rick McGuire 
I have started doing a little research on this, and I see how to implement
this on Windows, but I'm not sure the existing client/server set up will
work with *ix named pipes. The rxapi process handles requests like this:

Main thread binds to a port
Main thread listens for an inbound connection, which will be a new process
where rexx is being used.
A new thread is

On Fri, Mar 30, 2018 at 2:10 PM Moritz Hoffmann  wrote:

> The pipes-based version has one rxapi deamon per user. In fact, the pipe
> file is owned and only accessible by the user that spawned the rxapi
> daemon. That means another user has no way of accessing the pipe. I should
> have some time tomorrow so I can see how much work it is for *nix, but I'd
> need someone else to look at the Windows part (although the Windows doc
> seems to be quite clear about named pipes, just have to get my development
> environment up.)
>
> Moritz
>
> On Fri, Mar 30, 2018 at 6:47 PM, Rick McGuire 
> wrote:
>
>> Does the pipes-based version have real user isolation? In other words, do
>> you end up with one process per user? That would be a very good thing if we
>> can get the real isolation. However, I think I share your opinion about
>> trying to rush a replacement into 5.0.0. Historically, the rxapi daemon has
>> been the source of a lot of problems whenever things have changed, so any
>> replacement should get a lot of use and exposure before doing a roll out.
>>
>> Rick
>>
>> On Fri, Mar 30, 2018 at 12:40 PM, Moritz Hoffmann 
>> wrote:
>>
>>> Hi,
>>> yes, I was playing around with supporting pipes as another means of
>>> binding to the rxapi daemon. It was a rather simple change, the main effort
>>> was in extending/changing the communication abstraction classes not to
>>> assume they were socket-based. I had it running on Linux and I assume the
>>> same functionality would be available on MacOS, but I've no experience on
>>> how to use pipes in Windows. Quite sure they exist though!
>>>
>>> I'm not too sure we should include it in the 5.0.0 release. Firstly, it
>>> will require some testing and I'm sure it will have bugs at the beginning,
>>> just due to the fact that the pipe file needs to be stored somewhere and
>>> that might be different depending on the Linux distribution. Secondly, the
>>> rxapi daemon works fine at the moment.
>>>
>>> The only problem I see with the rxapi daemon is that it does not provide
>>> any isolation of users on the same host. The user id is passed as data in
>>> the messages so it's easy to patch ooRexx to use a different id instead. I
>>> guess we could call it a known and currently accepted vulnerability. Anyone
>>> who can connect to localhost can access the shared api daemon.
>>>
>>> If there's interest I could spin up the pipes-based version. Should take
>>> too long, just let me know.
>>>
>>> Moritz
>>>
>>> On Fri, Mar 30, 2018 at 5:02 PM, René Jansen  wrote:
>>>
 Moritz,

 After Gil’s talk I am also excited about ADDRESS WITH (and the fact
 that it has been taken up by Rick) so we might hold off the freeze for some
 time until we have all infrastructure and installers ready (and maybe have
 ADDRESS WITH). Maybe this gives us also time to look into the portable
 version again. I personally think this would be a great boost for takeup.

 I remember you had a set of patches to turn the sockets of rxapi into
 pipes. I do not remember if this was windows-only or also included
 linux/macos.

 The issues with rxapi:

 - you must be authorized to run it on its port
 - the firewall must allow access (cost me great headaches on Z, where
 the standard image for a Linux VM was very restrictive, and you got a
 timeout and no message)
 - you must be authorized to start it, so that means a service on
 windows or some systemd / startup item
 - it writes a PID file so whoever starts it, must be authorized to
 write there

 Thing is, solutions must work for the three main platforms, that is the
 reason of my question.

 best regards,


 René




 --
 Check out the vibrant tech community on one of the world's most
 engaging tech sites, Slashdot.org! http://sdm.link/slashdot
 ___
 Oorexx-devel mailing list
 Oorexx-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/oorexx-devel

>>>
>>>
>>>
>>> --
>>> Moritz Hoffmann;
>>> http://antiguru.de/
>>>
>>>
>>> --
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> ___
>>> Oorexx-devel mailing list
>>> Oorexx-devel@lists.sourceforge.net
>>>

Re: [Oorexx-devel] portable (usb) ooRexx 5.00

2018-03-30 Thread P.O. Jonsson 
Dear developers,

I think the discussion have gone off in another direction than the title 
proposes (I have no opinion on that matter) but for what it is worth I just now 
created an ooRexx installation that runs of a USB stick, with no use of 
superuser powers whatsoever.

It is only for MAC but the idea is extremely simple and should be possible to 
take to other platforms: During the CMake I redirected the installation to 
/volumes/. After that the only thing I needed to do was to 
amend the path.

Can be found here, instructions for use in the dmg image, just mount it and 
read howto.txt. 

https://www.dropbox.com/sh/p66c7g01h4jz5ss/AAAZd_Q2yQddrTHagxPo_UiTa?dl=0 



Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se




> Am 30.03.2018 um 17:02 schrieb René Jansen :
> 
> Moritz,
> 
> After Gil’s talk I am also excited about ADDRESS WITH (and the fact that it 
> has been taken up by Rick) so we might hold off the freeze for some time 
> until we have all infrastructure and installers ready (and maybe have ADDRESS 
> WITH). Maybe this gives us also time to look into the portable version again. 
> I personally think this would be a great boost for takeup.
> 
> I remember you had a set of patches to turn the sockets of rxapi into pipes. 
> I do not remember if this was windows-only or also included linux/macos.
> 
> The issues with rxapi:
> 
> - you must be authorized to run it on its port
> - the firewall must allow access (cost me great headaches on Z, where the 
> standard image for a Linux VM was very restrictive, and you got a timeout and 
> no message)
> - you must be authorized to start it, so that means a service on windows or 
> some systemd / startup item
> - it writes a PID file so whoever starts it, must be authorized to write there
> 
> Thing is, solutions must work for the three main platforms, that is the 
> reason of my question.
> 
> best regards,
> 
> 
> René
> 
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] portable (usb) ooRexx 5.00

2018-03-30 Thread Chip Davis 
I'm inclined to err on the side of caution, myself.  After all, this 
is introducing a new keyword for the ADDRESS statement with a 
potential for breakage; e.g.


  with = 'C:\Chip\bin\'
  Address COMMAND 'DIR' with

At the very least, that will generate an astonishing error message 
("Error 25: Invalid sub-keyword found" on Regina) in previously 
working code.  I don't think we should spring that on the community 
without a fair amount of warning.


We'll need  to update the existing test units for 'Address' and the docs.

Rick may have something ready in a week but I'm inclined to treat it 
as a prototype until we have all our other ducks in a row.  We have 
experience with, and thus a fairly high level of confidence in the 
current 5.0.0 release candidate.  Let's get it out unchanged and use 
it's announcement to draw attention to the long-awaited 'Address-With' 
feature, "coming soon".


ooRexx 4.2.0 has been out for four (!) years.  Let us not delay 5.0.0 
any longer.


-Chip-

On 3/30/2018 12:42 PM, Rick McGuire wrote:
Hmmm, I'm very much of the opposite opinion. I could have something 
working in a week or two. I've got a fair amount of the code written 
already, although I'm now at the tedious part of doing the command 
parsing and getting all of the error messages defined. The only part 
I'm really missing is the handling of the redirection of the actual 
command.


I do want to note that currently, I am only implementing the version 
of this that uses full command invocation, i.e.,


ADDRESS env command WITH INPUT STEM a.

But not the version where you set a persistent invocation state for an 
environment


ADDRESS env WITH INPUT STEM a.

There are some aspects of that I don't like, so I'm going to have to 
think that one over a bit. It might still be doable, but I'm not 
committing to it. The full command version is the part everybody 
wants, so we can always roll out the fuller support later if there is 
demand.


Rick

On Fri, Mar 30, 2018 at 11:51 AM, Gil Barmwater 
> wrote:


While I, too, am excited about ADDRESS WITH and am sure we will
move much more quickly with Rick's involvement than if I were
tackling it alone, I cannot estimate how long this will take to
complete.  So, my recommendation is to NOT hold the release of
5.0.0 for any longer than necessary to resolve the other issues
that have already been identified.  We can do a 5.1.0 when ADDRESS
WITH is ready and/or the RXAPI issues are resolved.  FWIW.

Gil

On 3/30/2018 11:02 AM, René Jansen wrote:

Moritz,

After Gil’s talk I am also excited about ADDRESS WITH (and the
fact that it has been taken up by Rick) so we might hold off
the freeze for some time until we have all infrastructure and
installers ready (and maybe have ADDRESS WITH). Maybe this
gives us also time to look into the portable version again. I
personally think this would be a great boost for takeup.

I remember you had a set of patches to turn the sockets of
rxapi into pipes. I do not remember if this was windows-only
or also included linux/macos.

The issues with rxapi:

- you must be authorized to run it on its port
- the firewall must allow access (cost me great headaches on
Z, where the standard image for a Linux VM was very
restrictive, and you got a timeout and no message)
- you must be authorized to start it, so that means a service
on windows or some systemd / startup item
- it writes a PID file so whoever starts it, must be
authorized to write there

Thing is, solutions must work for the three main platforms,
that is the reason of my question.

best regards,


René




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/oorexx-devel



-- 
Gil Barmwater





--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] portable (usb) ooRexx 5.00

2018-03-30 Thread Moritz Hoffmann 
The pipes-based version has one rxapi deamon per user. In fact, the pipe
file is owned and only accessible by the user that spawned the rxapi
daemon. That means another user has no way of accessing the pipe. I should
have some time tomorrow so I can see how much work it is for *nix, but I'd
need someone else to look at the Windows part (although the Windows doc
seems to be quite clear about named pipes, just have to get my development
environment up.)

Moritz

On Fri, Mar 30, 2018 at 6:47 PM, Rick McGuire  wrote:

> Does the pipes-based version have real user isolation? In other words, do
> you end up with one process per user? That would be a very good thing if we
> can get the real isolation. However, I think I share your opinion about
> trying to rush a replacement into 5.0.0. Historically, the rxapi daemon has
> been the source of a lot of problems whenever things have changed, so any
> replacement should get a lot of use and exposure before doing a roll out.
>
> Rick
>
> On Fri, Mar 30, 2018 at 12:40 PM, Moritz Hoffmann 
> wrote:
>
>> Hi,
>> yes, I was playing around with supporting pipes as another means of
>> binding to the rxapi daemon. It was a rather simple change, the main effort
>> was in extending/changing the communication abstraction classes not to
>> assume they were socket-based. I had it running on Linux and I assume the
>> same functionality would be available on MacOS, but I've no experience on
>> how to use pipes in Windows. Quite sure they exist though!
>>
>> I'm not too sure we should include it in the 5.0.0 release. Firstly, it
>> will require some testing and I'm sure it will have bugs at the beginning,
>> just due to the fact that the pipe file needs to be stored somewhere and
>> that might be different depending on the Linux distribution. Secondly, the
>> rxapi daemon works fine at the moment.
>>
>> The only problem I see with the rxapi daemon is that it does not provide
>> any isolation of users on the same host. The user id is passed as data in
>> the messages so it's easy to patch ooRexx to use a different id instead. I
>> guess we could call it a known and currently accepted vulnerability. Anyone
>> who can connect to localhost can access the shared api daemon.
>>
>> If there's interest I could spin up the pipes-based version. Should take
>> too long, just let me know.
>>
>> Moritz
>>
>> On Fri, Mar 30, 2018 at 5:02 PM, René Jansen  wrote:
>>
>>> Moritz,
>>>
>>> After Gil’s talk I am also excited about ADDRESS WITH (and the fact that
>>> it has been taken up by Rick) so we might hold off the freeze for some time
>>> until we have all infrastructure and installers ready (and maybe have
>>> ADDRESS WITH). Maybe this gives us also time to look into the portable
>>> version again. I personally think this would be a great boost for takeup.
>>>
>>> I remember you had a set of patches to turn the sockets of rxapi into
>>> pipes. I do not remember if this was windows-only or also included
>>> linux/macos.
>>>
>>> The issues with rxapi:
>>>
>>> - you must be authorized to run it on its port
>>> - the firewall must allow access (cost me great headaches on Z, where
>>> the standard image for a Linux VM was very restrictive, and you got a
>>> timeout and no message)
>>> - you must be authorized to start it, so that means a service on windows
>>> or some systemd / startup item
>>> - it writes a PID file so whoever starts it, must be authorized to write
>>> there
>>>
>>> Thing is, solutions must work for the three main platforms, that is the
>>> reason of my question.
>>>
>>> best regards,
>>>
>>>
>>> René
>>>
>>>
>>>
>>> 
>>> --
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> ___
>>> Oorexx-devel mailing list
>>> Oorexx-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>>
>>
>>
>>
>> --
>> Moritz Hoffmann;
>> http://antiguru.de/
>>
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>
>>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>


-- 
Moritz Hoffmann;
http://antiguru.de/

Re: [Oorexx-devel] portable (usb) ooRexx 5.00

2018-03-30 Thread Gil Barmwater 
My concern with getting this done is the support for *ix systems.  I 
need to figure out the correct mechanism to do the redirection and write 
the corresponding code.  Then there is the issue of getting a *ix build 
and testing that build in a *ix environment, neither of which can I do 
at the moment.


As to postponing the persistent state portion, I guess I can live with 
that but having it from the start will make documentation of the 
functionality cleaner.  (If it's not there initially, we need to clearly 
state that fact and then remove the restriction later when it gets added.)


Gil

PS The ANSI standard does define error messages in the BNF description 
which might also help with doing the parsing.  There is a link 
(http://www.rexxla.org/rexxlang/standards/j18pub.pdf) to the approved 
final draft and page 35 has the BNF for the ADDRESS keyword.  FWIW  GB


On 3/30/2018 12:42 PM, Rick McGuire wrote:
Hmmm, I'm very much of the opposite opinion. I could have something 
working in a week or two. I've got a fair amount of the code written 
already, although I'm now at the tedious part of doing the command 
parsing and getting all of the error messages defined. The only part 
I'm really missing is the handling of the redirection of the actual 
command.


I do want to note that currently, I am only implementing the version 
of this that uses full command invocation, i.e.,


ADDRESS env command WITH INPUT STEM a.

But not the version where you set a persistent invocation state for an 
environment


ADDRESS env WITH INPUT STEM a.

There are some aspects of that I don't like, so I'm going to have to 
think that one over a bit. It might still be doable, but I'm not 
committing to it. The full command version is the part everybody 
wants, so we can always roll out the fuller support later if there is 
demand.


Rick

On Fri, Mar 30, 2018 at 11:51 AM, Gil Barmwater 
> wrote:


While I, too, am excited about ADDRESS WITH and am sure we will
move much more quickly with Rick's involvement than if I were
tackling it alone, I cannot estimate how long this will take to
complete.  So, my recommendation is to NOT hold the release of
5.0.0 for any longer than necessary to resolve the other issues
that have already been identified.  We can do a 5.1.0 when ADDRESS
WITH is ready and/or the RXAPI issues are resolved.  FWIW.

Gil

On 3/30/2018 11:02 AM, René Jansen wrote:

Moritz,

After Gil’s talk I am also excited about ADDRESS WITH (and the
fact that it has been taken up by Rick) so we might hold off
the freeze for some time until we have all infrastructure and
installers ready (and maybe have ADDRESS WITH). Maybe this
gives us also time to look into the portable version again. I
personally think this would be a great boost for takeup.

I remember you had a set of patches to turn the sockets of
rxapi into pipes. I do not remember if this was windows-only
or also included linux/macos.

The issues with rxapi:

- you must be authorized to run it on its port
- the firewall must allow access (cost me great headaches on
Z, where the standard image for a Linux VM was very
restrictive, and you got a timeout and no message)
- you must be authorized to start it, so that means a service
on windows or some systemd / startup item
- it writes a PID file so whoever starts it, must be
authorized to write there

Thing is, solutions must work for the three main platforms,
that is the reason of my question.

best regards,


René




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/oorexx-devel



-- 
Gil Barmwater





--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/oorexx-devel





--
Check out the vibrant tech community on one of the world's most
engaging tech sites,

Re: [Oorexx-devel] portable (usb) ooRexx 5.00

2018-03-30 Thread Rick McGuire 
Does the pipes-based version have real user isolation? In other words, do
you end up with one process per user? That would be a very good thing if we
can get the real isolation. However, I think I share your opinion about
trying to rush a replacement into 5.0.0. Historically, the rxapi daemon has
been the source of a lot of problems whenever things have changed, so any
replacement should get a lot of use and exposure before doing a roll out.

Rick

On Fri, Mar 30, 2018 at 12:40 PM, Moritz Hoffmann 
wrote:

> Hi,
> yes, I was playing around with supporting pipes as another means of
> binding to the rxapi daemon. It was a rather simple change, the main effort
> was in extending/changing the communication abstraction classes not to
> assume they were socket-based. I had it running on Linux and I assume the
> same functionality would be available on MacOS, but I've no experience on
> how to use pipes in Windows. Quite sure they exist though!
>
> I'm not too sure we should include it in the 5.0.0 release. Firstly, it
> will require some testing and I'm sure it will have bugs at the beginning,
> just due to the fact that the pipe file needs to be stored somewhere and
> that might be different depending on the Linux distribution. Secondly, the
> rxapi daemon works fine at the moment.
>
> The only problem I see with the rxapi daemon is that it does not provide
> any isolation of users on the same host. The user id is passed as data in
> the messages so it's easy to patch ooRexx to use a different id instead. I
> guess we could call it a known and currently accepted vulnerability. Anyone
> who can connect to localhost can access the shared api daemon.
>
> If there's interest I could spin up the pipes-based version. Should take
> too long, just let me know.
>
> Moritz
>
> On Fri, Mar 30, 2018 at 5:02 PM, René Jansen  wrote:
>
>> Moritz,
>>
>> After Gil’s talk I am also excited about ADDRESS WITH (and the fact that
>> it has been taken up by Rick) so we might hold off the freeze for some time
>> until we have all infrastructure and installers ready (and maybe have
>> ADDRESS WITH). Maybe this gives us also time to look into the portable
>> version again. I personally think this would be a great boost for takeup.
>>
>> I remember you had a set of patches to turn the sockets of rxapi into
>> pipes. I do not remember if this was windows-only or also included
>> linux/macos.
>>
>> The issues with rxapi:
>>
>> - you must be authorized to run it on its port
>> - the firewall must allow access (cost me great headaches on Z, where the
>> standard image for a Linux VM was very restrictive, and you got a timeout
>> and no message)
>> - you must be authorized to start it, so that means a service on windows
>> or some systemd / startup item
>> - it writes a PID file so whoever starts it, must be authorized to write
>> there
>>
>> Thing is, solutions must work for the three main platforms, that is the
>> reason of my question.
>>
>> best regards,
>>
>>
>> René
>>
>>
>>
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>
>
>
>
> --
> Moritz Hoffmann;
> http://antiguru.de/
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] portable (usb) ooRexx 5.00

2018-03-30 Thread Rick McGuire 
Hmmm, I'm very much of the opposite opinion. I could have something working
in a week or two. I've got a fair amount of the code written already,
although I'm now at the tedious part of doing the command parsing and
getting all of the error messages defined. The only part I'm really missing
is the handling of the redirection of the actual command.

I do want to note that currently, I am only implementing the version of
this that uses full command invocation, i.e.,

ADDRESS env command WITH INPUT STEM a.

But not the version where you set a persistent invocation state for an
environment

ADDRESS env WITH INPUT STEM a.

There are some aspects of that I don't like, so I'm going to have to think
that one over a bit. It might still be doable, but I'm not committing to
it. The full command version is the part everybody wants, so we can always
roll out the fuller support later if there is demand.

Rick

On Fri, Mar 30, 2018 at 11:51 AM, Gil Barmwater 
wrote:

> While I, too, am excited about ADDRESS WITH and am sure we will move much
> more quickly with Rick's involvement than if I were tackling it alone, I
> cannot estimate how long this will take to complete.  So, my recommendation
> is to NOT hold the release of 5.0.0 for any longer than necessary to
> resolve the other issues that have already been identified.  We can do a
> 5.1.0 when ADDRESS WITH is ready and/or the RXAPI issues are resolved.
> FWIW.
>
> Gil
>
> On 3/30/2018 11:02 AM, René Jansen wrote:
>
>> Moritz,
>>
>> After Gil’s talk I am also excited about ADDRESS WITH (and the fact that
>> it has been taken up by Rick) so we might hold off the freeze for some time
>> until we have all infrastructure and installers ready (and maybe have
>> ADDRESS WITH). Maybe this gives us also time to look into the portable
>> version again. I personally think this would be a great boost for takeup.
>>
>> I remember you had a set of patches to turn the sockets of rxapi into
>> pipes. I do not remember if this was windows-only or also included
>> linux/macos.
>>
>> The issues with rxapi:
>>
>> - you must be authorized to run it on its port
>> - the firewall must allow access (cost me great headaches on Z, where the
>> standard image for a Linux VM was very restrictive, and you got a timeout
>> and no message)
>> - you must be authorized to start it, so that means a service on windows
>> or some systemd / startup item
>> - it writes a PID file so whoever starts it, must be authorized to write
>> there
>>
>> Thing is, solutions must work for the three main platforms, that is the
>> reason of my question.
>>
>> best regards,
>>
>>
>> René
>>
>>
>>
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>
>
> --
> Gil Barmwater
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] portable (usb) ooRexx 5.00

2018-03-30 Thread Moritz Hoffmann 
Hi,
yes, I was playing around with supporting pipes as another means of binding
to the rxapi daemon. It was a rather simple change, the main effort was in
extending/changing the communication abstraction classes not to assume they
were socket-based. I had it running on Linux and I assume the same
functionality would be available on MacOS, but I've no experience on how to
use pipes in Windows. Quite sure they exist though!

I'm not too sure we should include it in the 5.0.0 release. Firstly, it
will require some testing and I'm sure it will have bugs at the beginning,
just due to the fact that the pipe file needs to be stored somewhere and
that might be different depending on the Linux distribution. Secondly, the
rxapi daemon works fine at the moment.

The only problem I see with the rxapi daemon is that it does not provide
any isolation of users on the same host. The user id is passed as data in
the messages so it's easy to patch ooRexx to use a different id instead. I
guess we could call it a known and currently accepted vulnerability. Anyone
who can connect to localhost can access the shared api daemon.

If there's interest I could spin up the pipes-based version. Should take
too long, just let me know.

Moritz

On Fri, Mar 30, 2018 at 5:02 PM, René Jansen  wrote:

> Moritz,
>
> After Gil’s talk I am also excited about ADDRESS WITH (and the fact that
> it has been taken up by Rick) so we might hold off the freeze for some time
> until we have all infrastructure and installers ready (and maybe have
> ADDRESS WITH). Maybe this gives us also time to look into the portable
> version again. I personally think this would be a great boost for takeup.
>
> I remember you had a set of patches to turn the sockets of rxapi into
> pipes. I do not remember if this was windows-only or also included
> linux/macos.
>
> The issues with rxapi:
>
> - you must be authorized to run it on its port
> - the firewall must allow access (cost me great headaches on Z, where the
> standard image for a Linux VM was very restrictive, and you got a timeout
> and no message)
> - you must be authorized to start it, so that means a service on windows
> or some systemd / startup item
> - it writes a PID file so whoever starts it, must be authorized to write
> there
>
> Thing is, solutions must work for the three main platforms, that is the
> reason of my question.
>
> best regards,
>
>
> René
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>



-- 
Moritz Hoffmann;
http://antiguru.de/
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] portable (usb) ooRexx 5.00

2018-03-30 Thread René Jansen 
Hi Gil,

True - that might be better. And a year passes quickly, as we have seen. I am 
starting on the transports to SF, release notes and docs.

@Erich, it is not really necessary to actually build the docs on all platforms? 
Do they have any dependencies there?

René.

> On 30 Mar 2018, at 11:51, Gil Barmwater  wrote:
> 
> While I, too, am excited about ADDRESS WITH and am sure we will move much 
> more quickly with Rick's involvement than if I were tackling it alone, I 
> cannot estimate how long this will take to complete.  So, my recommendation 
> is to NOT hold the release of 5.0.0 for any longer than necessary to resolve 
> the other issues that have already been identified.  We can do a 5.1.0 when 
> ADDRESS WITH is ready and/or the RXAPI issues are resolved.  FWIW.
> 
> Gil
>> On 3/30/2018 11:02 AM, René Jansen wrote:
>> Moritz,
>> 
>> After Gil’s talk I am also excited about ADDRESS WITH (and the fact that it 
>> has been taken up by Rick) so we might hold off the freeze for some time 
>> until we have all infrastructure and installers ready (and maybe have 
>> ADDRESS WITH). Maybe this gives us also time to look into the portable 
>> version again. I personally think this would be a great boost for takeup.
>> 
>> I remember you had a set of patches to turn the sockets of rxapi into pipes. 
>> I do not remember if this was windows-only or also included linux/macos.
>> 
>> The issues with rxapi:
>> 
>> - you must be authorized to run it on its port
>> - the firewall must allow access (cost me great headaches on Z, where the 
>> standard image for a Linux VM was very restrictive, and you got a timeout 
>> and no message)
>> - you must be authorized to start it, so that means a service on windows or 
>> some systemd / startup item
>> - it writes a PID file so whoever starts it, must be authorized to write 
>> there
>> 
>> Thing is, solutions must work for the three main platforms, that is the 
>> reason of my question.
>> 
>> best regards,
>> 
>> 
>> René
>> 
>> 
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
> 
> -- 
> Gil Barmwater
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] portable (usb) ooRexx 5.00

2018-03-30 Thread Gil Barmwater 
While I, too, am excited about ADDRESS WITH and am sure we will move 
much more quickly with Rick's involvement than if I were tackling it 
alone, I cannot estimate how long this will take to complete.  So, my 
recommendation is to NOT hold the release of 5.0.0 for any longer than 
necessary to resolve the other issues that have already been 
identified.  We can do a 5.1.0 when ADDRESS WITH is ready and/or the 
RXAPI issues are resolved.  FWIW.


Gil
On 3/30/2018 11:02 AM, René Jansen wrote:

Moritz,

After Gil’s talk I am also excited about ADDRESS WITH (and the fact that it has 
been taken up by Rick) so we might hold off the freeze for some time until we 
have all infrastructure and installers ready (and maybe have ADDRESS WITH). 
Maybe this gives us also time to look into the portable version again. I 
personally think this would be a great boost for takeup.

I remember you had a set of patches to turn the sockets of rxapi into pipes. I 
do not remember if this was windows-only or also included linux/macos.

The issues with rxapi:

- you must be authorized to run it on its port
- the firewall must allow access (cost me great headaches on Z, where the 
standard image for a Linux VM was very restrictive, and you got a timeout and 
no message)
- you must be authorized to start it, so that means a service on windows or 
some systemd / startup item
- it writes a PID file so whoever starts it, must be authorized to write there

Thing is, solutions must work for the three main platforms, that is the reason 
of my question.

best regards,


René



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel


--
Gil Barmwater


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] portable (usb) ooRexx 5.00

2018-03-30 Thread René Jansen 
Moritz,

After Gil’s talk I am also excited about ADDRESS WITH (and the fact that it has 
been taken up by Rick) so we might hold off the freeze for some time until we 
have all infrastructure and installers ready (and maybe have ADDRESS WITH). 
Maybe this gives us also time to look into the portable version again. I 
personally think this would be a great boost for takeup.

I remember you had a set of patches to turn the sockets of rxapi into pipes. I 
do not remember if this was windows-only or also included linux/macos.

The issues with rxapi:

- you must be authorized to run it on its port
- the firewall must allow access (cost me great headaches on Z, where the 
standard image for a Linux VM was very restrictive, and you got a timeout and 
no message)
- you must be authorized to start it, so that means a service on windows or 
some systemd / startup item
- it writes a PID file so whoever starts it, must be authorized to write there

Thing is, solutions must work for the three main platforms, that is the reason 
of my question.

best regards,


René



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel