peasthope@shaw.ca wrote: > Bob Proulx wrote: > > I think hacking the ftp backend will always be problematic. > > Understood. Really I meant that the ETHO operating system would > have to be replaced with Linux or Plan 9 or Inferno. Possible but not > appealing. I think you can do it without. But I know nothing of Oberon. What scripting environments are available there? Is a standard POSIX sh available? Perl? Other? > > Is it possible to script a file transfer process? > > Yes, with ET.Do <ScriptFile>. Then I think you should be able to make this work satisfactory. > > Put the file you want into an incoming dropbox first. Then upload > > an additional control file along with it. > > The mere presence of a static control file can never make a freshly > uploaded script executable? Always something must trigger the change > in permission? Correct. Originally I was thinking the control file would have some type of syntax that I will make up here in the moment such as: Name: examplefile1 SHA1: 044b46ab5e37d04ca14b5b85a8332d1f7309f62f Mode: a+rx User: peasthope Group: peasthope Location: /path/to/dest/examplefile1 Then a script could read the file, extract the checksum, name, permissions, user and group information. Then if and only if the checksum matches then it would act upon the mode-user-group and install the file in the desired location. That was my original thought. > What about making a wrapper for the script interpreter? The wrapper > would first make the script executable and then apply the interpreter. The idea of uploading a script and then running the script on the remote machine is probably fine for your environment. It wasn't my first thought. It feels more scary. But actually is the same. So if you want to go that way that is fine. And actually, with more thought, I cannot think of any reason why my original proposal isn't just as insecure. And therefore your suggestion is better because it is simpler. All other things being the same then simpler is always better. chmod a+rx examplefile1 chown peasthope:peasthope examplefile1 mv examplefile1 /path/to/dest/examplefile1 You don't need to make this wrapper executable if you are okay with pre-selecting the interpreter. Simply run an interpreter upon it such as 'sh ./script'. Changing it to be executable first allows you to choose the interpreter at runtime with #!/path. > > at some point in the future it would be easy to convert this to > > using gpg signed files and then it would be secure even over an > > insecure network. A plus for a future expansion.. > > Interesting idea. That would use the extant SSH code in ETHO along > with newly written code to implement gpg? There isn't any ssh code in gpg. You could also use OpenSSL or GNUTLS to implement cryptographic signatures. > ETHO is elegant but not mature. Needs more features. The more we > have, the more we need ... or at least want. Or much more simply you could do integrity checking using HMAC. Since all that is needed is simple signing and if you are on a developing system without a lot of features then all you need are message digests. http://en.wikipedia.org/wiki/Hmac I would implement signature checking at the earliest practical time. It prevents a lot of potential attacks. Best to do it before you need it. Bob
Attachment:
signature.asc
Description: Digital signature