I am clueless when it comes to encryption and safety , so as you would expect I will offer my opinion on this. I do not think that encryption from the side of Pharo would be a good idea because having the image you have access to everything . Including any kind of context even its not stored in a variable. I think the safest way is not to use Pharo and do this in C and put this in a DLL which Pharo cannot access other than calling its functions. This way you can be certain that the user has no way to hack the data unless of course its disassemble the DLL and inspect the memory but that would be much harder than do it in Pharo. Of course an average Pharo user/coder does not have this technical knowledge , sometime we cannot even figure out UFFI problems but a determined hacker wont have an issue disassembling the DLL (reading the machine code). Of course you could use one of the countless security libraries for C from Pharo using UFFI. But yeah personally I would not allow Pharo to have any kind of access to that information just call DLL function that will reply only if a yes/no about the success of the login attempt. The rest I would leave it to my DLL and the C security library. But then I am not a believer of safety of any kind. Life is very unsafe but of course its wise to try to make it safer :) On Wed, Aug 16, 2017 at 7:55 PM Tim Mackinnon <tim@testit.works> wrote:
Hi - Iâm struggling to find something that I saw that discussed this issue kind of.
In my image (its actually a headless one - but this could apply to a fat image too) - I build an application that needs access to a service (in this case an S3 bucket).
The AWS library Iâm using (but others are similar) has an AWSLogin class singleton where I can specify a username and password. So in a playground I can do that and test it all works etc.
However, for deployment its never a good idea to encode this info into your code (particularly if you use Iceberg and GitHub) - SO, I am using secret variable support in GitLab - which Iâve seen many projects do in other languages. This way, I type in those details into an encrypted place in the CI and it then exposes them as temporary variables when I build my system (so far so good).
Now in my build - I run a little script like this and pass on those variables (neatly, Gitlab doesnât show their values in its logs):
./pharo Pharo.image --no-default-preferences --save --quit st config.st \ *"{**â**$USER'. â$PWD'}"*
In config.st I then extract these command line parameters (the ST handler nicely exposes the extra parameter array so I didnât have to do anything custom)
"Expect image to be called with params as a last arg array" config := Array readFrom: Smalltalk arguments last. *user* := config at: 1. *pwd* := config at: 2.
DBConfig default accessKey: user; pKey: pwd; yourself.
So it all looks pretty good so far - however it occurs to me that if you get hold of a .image and were to browse all of the Strings - e.g.
./pharo Pharo.image eval "(ByteString allInstances)â
I think you would ulimtately find those strings unless the Class encrypts them in some way right?
So Iâm wondering why we donât have an EncryptedString object for just this (Iâve seen lots of cryptography libraries etc), but isnât this quite a common thing to deal with? And should Pharo provide something that library writers adopt to encourage better image safety? Or am I wrong in my analysis?
Tim