pharo-users@lists.pharo.org

Any question about pharo is welcome

View all threads

[ Security ] Accessing private information from Pharo image

SR
sergio ruiz
Wed, Jan 17, 2024 4:27 AM

Hi, all.

One of my projects logs in to Spaces (Digital Ocean’s version of S3). I need to be able access the credentials, but I don’t want to store them in the source code, as I will be using Github to store the projects.

Is there an accepted way to do this (encryption)?

Should I store them on the system as environment variables? is this efficient?

thanks!


peace,
sergio
photographer, journalist, visionary

Public Key: https://pgp.key-server.io/pks/lookup?op=get&search=0x69B08F58923AB3A2
#BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV
@sergio_101@mastodon.social
https://sergio101.com
http://www.codeandmusic.com
http://www.twitter.com/sergio_101
http://www.facebook.com/sergio101

Hi, all. One of my projects logs in to Spaces (Digital Ocean’s version of S3). I need to be able access the credentials, but I don’t want to store them in the source code, as I will be using Github to store the projects. Is there an accepted way to do this (encryption)? Should I store them on the system as environment variables? is this efficient? thanks! ---- peace, sergio photographer, journalist, visionary Public Key: https://pgp.key-server.io/pks/lookup?op=get&search=0x69B08F58923AB3A2 #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV @sergio_101@mastodon.social https://sergio101.com http://www.codeandmusic.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101
JF
James Foster
Wed, Jan 17, 2024 4:58 AM

Dear Sergio,

You are right that passwords and credentials should not be committed to source code. There are several alternatives available.

If you are running the code on your own machine, logged as you, then I would just keep the credentials in ~/.ssh as a private key. Another place for the credentials might be something like /var/opt/MYAPP/myPrivateKey. In any case, ensure that you protect the key with 400 or 600 security (this assumes you are using Linux or macOS).

James Foster

On Jan 16, 2024, at 8:27 PM, sergio ruiz sergio.rrd@gmail.com wrote:

Hi, all.

One of my projects logs in to Spaces (Digital Ocean’s version of S3). I need to be able access the credentials, but I don’t want to store them in the source code, as I will be using Github to store the projects.

Is there an accepted way to do this (encryption)?

Should I store them on the system as environment variables? is this efficient?

thanks!


peace,
sergio
photographer, journalist, visionary

Public Key: https://pgp.key-server.io/pks/lookup?op=get&search=0x69B08F58923AB3A2
#BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV
@sergio_101@mastodon.social
https://sergio101.com
http://www.codeandmusic.com
http://www.twitter.com/sergio_101
http://www.facebook.com/sergio101

Dear Sergio, You are right that passwords and credentials should not be committed to source code. There are several alternatives available. If you are running the code on your own machine, logged as you, then I would just keep the credentials in ~/.ssh as a private key. Another place for the credentials might be something like /var/opt/MYAPP/myPrivateKey. In any case, ensure that you protect the key with 400 or 600 security (this assumes you are using Linux or macOS). James Foster > On Jan 16, 2024, at 8:27 PM, sergio ruiz <sergio.rrd@gmail.com> wrote: > > Hi, all. > > One of my projects logs in to Spaces (Digital Ocean’s version of S3). I need to be able access the credentials, but I don’t want to store them in the source code, as I will be using Github to store the projects. > > Is there an accepted way to do this (encryption)? > > Should I store them on the system as environment variables? is this efficient? > > thanks! > > > ---- > peace, > sergio > photographer, journalist, visionary > > Public Key: https://pgp.key-server.io/pks/lookup?op=get&search=0x69B08F58923AB3A2 > #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV > @sergio_101@mastodon.social > https://sergio101.com > http://www.codeandmusic.com > http://www.twitter.com/sergio_101 > http://www.facebook.com/sergio101 >
SR
sergio ruiz
Wed, Jan 17, 2024 5:14 AM

Gotcha. I am developing on a Mac, but in production, it will be running on a linux machine.

Thanks!

On Jan 16, 2024, at 11:58 PM, James Foster via Pharo-users pharo-users@lists.pharo.org wrote:

If you are running the code on your own machine, logged as you, then I would just keep the credentials in ~/.ssh as a private key. Another place for the credentials might be something like /var/opt/MYAPP/myPrivateKey. In any case, ensure that you protect the key with 400 or 600 security (this assumes you are using Linux or macOS).

Gotcha. I am developing on a Mac, but in production, it will be running on a linux machine. Thanks! > On Jan 16, 2024, at 11:58 PM, James Foster via Pharo-users <pharo-users@lists.pharo.org> wrote: > > If you are running the code on your own machine, logged as you, then I would just keep the credentials in ~/.ssh as a private key. Another place for the credentials might be something like /var/opt/MYAPP/myPrivateKey. In any case, ensure that you protect the key with 400 or 600 security (this assumes you are using Linux or macOS). ---- peace, sergio photographer, journalist, visionary Public Key: https://pgp.key-server.io/pks/lookup?op=get&search=0x69B08F58923AB3A2 #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV @sergio_101@mastodon.social https://sergio101.com http://www.codeandmusic.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101
NH
Norbert Hartl
Wed, Jan 17, 2024 9:31 AM

Am 17.01.2024 um 05:27 schrieb sergio ruiz sergio.rrd@gmail.com:

Hi, all.

One of my projects logs in to Spaces (Digital Ocean’s version of S3). I need to be able access the credentials, but I don’t want to store them in the source code, as I will be using Github to store the projects.

Is there an accepted way to do this (encryption)?

Should I store them on the system as environment variables? is this efficient?

One of the usualy ways especially on unix systems is to hand credentials in via the process environment. If you execute

OSEnvironment current at: ‚SHELL'

in a playground you should see somthing like ‚/bin/bash‘. So when starting the process you just need to specify the environment variables so that pharo can access it. If you use docker there is a way to specify that easily.

Norbert

> Am 17.01.2024 um 05:27 schrieb sergio ruiz <sergio.rrd@gmail.com>: > > Hi, all. > > One of my projects logs in to Spaces (Digital Ocean’s version of S3). I need to be able access the credentials, but I don’t want to store them in the source code, as I will be using Github to store the projects. > > Is there an accepted way to do this (encryption)? > > Should I store them on the system as environment variables? is this efficient? One of the usualy ways especially on unix systems is to hand credentials in via the process environment. If you execute OSEnvironment current at: ‚SHELL' in a playground you should see somthing like ‚/bin/bash‘. So when starting the process you just need to specify the environment variables so that pharo can access it. If you use docker there is a way to specify that easily. Norbert
RO
Richard O'Keefe
Wed, Jan 17, 2024 11:31 AM

Back in the days when an entire department would share something like
a VAX and think themselves
lucky, the advance was never to let secrets rest in your address
space any longer than you had to.
Bring the secret into memory just the instant before you need it, use
it, then scrub that area of
memory. You might want to put the credentials on a thumb drive which
is plugged in only when needed,
I've generally found it better for environment variables to contain
file names pointing to configuration
files than to have then hold the configuration information directly.

On Wed, 17 Jan 2024 at 22:31, Norbert Hartl norbert@hartl.name wrote:

Am 17.01.2024 um 05:27 schrieb sergio ruiz sergio.rrd@gmail.com:

Hi, all.

One of my projects logs in to Spaces (Digital Ocean’s version of S3). I need to be able access the credentials, but I don’t want to store them in the source code, as I will be using Github to store the projects.

Is there an accepted way to do this (encryption)?

Should I store them on the system as environment variables? is this efficient?

One of the usualy ways especially on unix systems is to hand credentials in via the process environment. If you execute

OSEnvironment current at: ‚SHELL'

in a playground you should see somthing like ‚/bin/bash‘. So when starting the process you just need to specify the environment variables so that pharo can access it. If you use docker there is a way to specify that easily.

Norbert

Back in the days when an entire department would share something like a VAX and think themselves lucky, the advance was never to let secrets *rest* in your address space any longer than you had to. Bring the secret into memory just the instant before you need it, use it, then scrub that area of memory. You might want to put the credentials on a thumb drive which is plugged in only when needed, I've generally found it better for environment variables to contain file names pointing to configuration files than to have then hold the configuration information directly. On Wed, 17 Jan 2024 at 22:31, Norbert Hartl <norbert@hartl.name> wrote: > > > > > Am 17.01.2024 um 05:27 schrieb sergio ruiz <sergio.rrd@gmail.com>: > > > > Hi, all. > > > > One of my projects logs in to Spaces (Digital Ocean’s version of S3). I need to be able access the credentials, but I don’t want to store them in the source code, as I will be using Github to store the projects. > > > > Is there an accepted way to do this (encryption)? > > > > Should I store them on the system as environment variables? is this efficient? > > One of the usualy ways especially on unix systems is to hand credentials in via the process environment. If you execute > > OSEnvironment current at: ‚SHELL' > > in a playground you should see somthing like ‚/bin/bash‘. So when starting the process you just need to specify the environment variables so that pharo can access it. If you use docker there is a way to specify that easily. > > Norbert
NH
Norbert Hartl
Wed, Jan 17, 2024 11:55 AM

Am 17.01.2024 um 12:31 schrieb Richard O'Keefe raoknz@gmail.com:

Back in the days when an entire department would share something like
a VAX and think themselves
lucky, the advance was never to let secrets rest in your address
space any longer than you had to.
Bring the secret into memory just the instant before you need it, use
it, then scrub that area of
memory. You might want to put the credentials on a thumb drive which
is plugged in only when needed,

the example is about cloud servers. So we can rule out thumb drives easily ;) Scrubbing memory is only useful if you don’t need access at random which the examples sounds like.

I've generally found it better for environment variables to contain
file names pointing to configuration
files than to have then hold the configuration information directly.

If you use files you have just one more thing where you can screw up things like file permissions. And the question is where does the file come from? Especially if you use something like docker with ephemeral containers.

Norbert

On Wed, 17 Jan 2024 at 22:31, Norbert Hartl norbert@hartl.name wrote:

Am 17.01.2024 um 05:27 schrieb sergio ruiz sergio.rrd@gmail.com:

Hi, all.

One of my projects logs in to Spaces (Digital Ocean’s version of S3). I need to be able access the credentials, but I don’t want to store them in the source code, as I will be using Github to store the projects.

Is there an accepted way to do this (encryption)?

Should I store them on the system as environment variables? is this efficient?

One of the usualy ways especially on unix systems is to hand credentials in via the process environment. If you execute

OSEnvironment current at: ‚SHELL'

in a playground you should see somthing like ‚/bin/bash‘. So when starting the process you just need to specify the environment variables so that pharo can access it. If you use docker there is a way to specify that easily.

Norbert

> Am 17.01.2024 um 12:31 schrieb Richard O'Keefe <raoknz@gmail.com>: > > Back in the days when an entire department would share something like > a VAX and think themselves > lucky, the advance was never to let secrets *rest* in your address > space any longer than you had to. > Bring the secret into memory just the instant before you need it, use > it, then scrub that area of > memory. You might want to put the credentials on a thumb drive which > is plugged in only when needed, the example is about cloud servers. So we can rule out thumb drives easily ;) Scrubbing memory is only useful if you don’t need access at random which the examples sounds like. > I've generally found it better for environment variables to contain > file names pointing to configuration > files than to have then hold the configuration information directly. If you use files you have just one more thing where you can screw up things like file permissions. And the question is where does the file come from? Especially if you use something like docker with ephemeral containers. Norbert > > On Wed, 17 Jan 2024 at 22:31, Norbert Hartl <norbert@hartl.name> wrote: >> >> >> >>> Am 17.01.2024 um 05:27 schrieb sergio ruiz <sergio.rrd@gmail.com>: >>> >>> Hi, all. >>> >>> One of my projects logs in to Spaces (Digital Ocean’s version of S3). I need to be able access the credentials, but I don’t want to store them in the source code, as I will be using Github to store the projects. >>> >>> Is there an accepted way to do this (encryption)? >>> >>> Should I store them on the system as environment variables? is this efficient? >> >> One of the usualy ways especially on unix systems is to hand credentials in via the process environment. If you execute >> >> OSEnvironment current at: ‚SHELL' >> >> in a playground you should see somthing like ‚/bin/bash‘. So when starting the process you just need to specify the environment variables so that pharo can access it. If you use docker there is a way to specify that easily. >> >> Norbert
NB
Noury Bouraqadi
Wed, Jan 17, 2024 12:50 PM

Many cloud platforms provide a secrets manager. It sets up env variables with secrets you need.

Noury
On Jan 17 2024, at 12:55 pm, Norbert Hartl norbert@hartl.name wrote:

Am 17.01.2024 um 12:31 schrieb Richard O'Keefe raoknz@gmail.com:

Back in the days when an entire department would share something like
a VAX and think themselves
lucky, the advance was never to let secrets rest in your address
space any longer than you had to.
Bring the secret into memory just the instant before you need it, use
it, then scrub that area of
memory. You might want to put the credentials on a thumb drive which
is plugged in only when needed,

the example is about cloud servers. So we can rule out thumb drives easily ;) Scrubbing memory is only useful if you don’t need access at random which the examples sounds like.

I've generally found it better for environment variables to contain
file names pointing to configuration
files than to have then hold the configuration information directly.

If you use files you have just one more thing where you can screw up things like file permissions. And the question is where does the file come from? Especially if you use something like docker with ephemeral containers.
Norbert

On Wed, 17 Jan 2024 at 22:31, Norbert Hartl norbert@hartl.name wrote:

Am 17.01.2024 um 05:27 schrieb sergio ruiz sergio.rrd@gmail.com:

Hi, all.

One of my projects logs in to Spaces (Digital Ocean’s version of S3). I need to be able access the credentials, but I don’t want to store them in the source code, as I will be using Github to store the projects.

Is there an accepted way to do this (encryption)?

Should I store them on the system as environment variables? is this efficient?

One of the usualy ways especially on unix systems is to hand credentials in via the process environment. If you execute

OSEnvironment current at: ‚SHELL'

in a playground you should see somthing like ‚/bin/bash‘. So when starting the process you just need to specify the environment variables so that pharo can access it. If you use docker there is a way to specify that easily.

Norbert

Many cloud platforms provide a secrets manager. It sets up env variables with secrets you need. Noury On Jan 17 2024, at 12:55 pm, Norbert Hartl <norbert@hartl.name> wrote: > > > Am 17.01.2024 um 12:31 schrieb Richard O'Keefe <raoknz@gmail.com>: > > > > Back in the days when an entire department would share something like > > a VAX and think themselves > > lucky, the advance was never to let secrets *rest* in your address > > space any longer than you had to. > > Bring the secret into memory just the instant before you need it, use > > it, then scrub that area of > > memory. You might want to put the credentials on a thumb drive which > > is plugged in only when needed, > > the example is about cloud servers. So we can rule out thumb drives easily ;) Scrubbing memory is only useful if you don’t need access at random which the examples sounds like. > > I've generally found it better for environment variables to contain > > file names pointing to configuration > > files than to have then hold the configuration information directly. > > If you use files you have just one more thing where you can screw up things like file permissions. And the question is where does the file come from? Especially if you use something like docker with ephemeral containers. > Norbert > > > > On Wed, 17 Jan 2024 at 22:31, Norbert Hartl <norbert@hartl.name> wrote: > >> > >> > >> > >>> Am 17.01.2024 um 05:27 schrieb sergio ruiz <sergio.rrd@gmail.com>: > >>> > >>> Hi, all. > >>> > >>> One of my projects logs in to Spaces (Digital Ocean’s version of S3). I need to be able access the credentials, but I don’t want to store them in the source code, as I will be using Github to store the projects. > >>> > >>> Is there an accepted way to do this (encryption)? > >>> > >>> Should I store them on the system as environment variables? is this efficient? > >> > >> One of the usualy ways especially on unix systems is to hand credentials in via the process environment. If you execute > >> > >> OSEnvironment current at: ‚SHELL' > >> > >> in a playground you should see somthing like ‚/bin/bash‘. So when starting the process you just need to specify the environment variables so that pharo can access it. If you use docker there is a way to specify that easily. > >> > >> Norbert >
NH
Norbert Hartl
Wed, Jan 17, 2024 1:04 PM

Am 17.01.2024 um 13:50 schrieb Noury Bouraqadi bouraqadi@gmail.com:

Many cloud platforms provide a secrets manager. It sets up env variables with secrets you need.

This is technically a good idea but legally probably bad. If you hand out cleartext credentials to your cloud provider you add that provider to the security chain. Would be interesting to read the terms & conditions for that. ;)  Or there is something really clever going on. Do you have any pointers?

thanks,

Norbert

Noury

On Jan 17 2024, at 12:55 pm, Norbert Hartl norbert@hartl.name wrote:

Am 17.01.2024 um 12:31 schrieb Richard O'Keefe raoknz@gmail.com:

Back in the days when an entire department would share something like
a VAX and think themselves
lucky, the advance was never to let secrets rest in your address
space any longer than you had to.
Bring the secret into memory just the instant before you need it, use
it, then scrub that area of
memory. You might want to put the credentials on a thumb drive which
is plugged in only when needed,

the example is about cloud servers. So we can rule out thumb drives easily ;) Scrubbing memory is only useful if you don’t need access at random which the examples sounds like.

I've generally found it better for environment variables to contain
file names pointing to configuration
files than to have then hold the configuration information directly.

If you use files you have just one more thing where you can screw up things like file permissions. And the question is where does the file come from? Especially if you use something like docker with ephemeral containers.

Norbert

On Wed, 17 Jan 2024 at 22:31, Norbert Hartl norbert@hartl.name wrote:

Am 17.01.2024 um 05:27 schrieb sergio ruiz sergio.rrd@gmail.com:

Hi, all.

One of my projects logs in to Spaces (Digital Ocean’s version of S3). I need to be able access the credentials, but I don’t want to store them in the source code, as I will be using Github to store the projects.

Is there an accepted way to do this (encryption)?

Should I store them on the system as environment variables? is this efficient?

One of the usualy ways especially on unix systems is to hand credentials in via the process environment. If you execute

OSEnvironment current at: ‚SHELL'

in a playground you should see somthing like ‚/bin/bash‘. So when starting the process you just need to specify the environment variables so that pharo can access it. If you use docker there is a way to specify that easily.

Norbert

> Am 17.01.2024 um 13:50 schrieb Noury Bouraqadi <bouraqadi@gmail.com>: > > Many cloud platforms provide a secrets manager. It sets up env variables with secrets you need. > This is technically a good idea but legally probably bad. If you hand out cleartext credentials to your cloud provider you add that provider to the security chain. Would be interesting to read the terms & conditions for that. ;) Or there is something really clever going on. Do you have any pointers? thanks, Norbert > Noury > > On Jan 17 2024, at 12:55 pm, Norbert Hartl <norbert@hartl.name> wrote: > > > Am 17.01.2024 um 12:31 schrieb Richard O'Keefe <raoknz@gmail.com>: > > > > Back in the days when an entire department would share something like > > a VAX and think themselves > > lucky, the advance was never to let secrets *rest* in your address > > space any longer than you had to. > > Bring the secret into memory just the instant before you need it, use > > it, then scrub that area of > > memory. You might want to put the credentials on a thumb drive which > > is plugged in only when needed, > > the example is about cloud servers. So we can rule out thumb drives easily ;) Scrubbing memory is only useful if you don’t need access at random which the examples sounds like. > > > I've generally found it better for environment variables to contain > > file names pointing to configuration > > files than to have then hold the configuration information directly. > > If you use files you have just one more thing where you can screw up things like file permissions. And the question is where does the file come from? Especially if you use something like docker with ephemeral containers. > > Norbert > > > > > On Wed, 17 Jan 2024 at 22:31, Norbert Hartl <norbert@hartl.name> wrote: > >> > >> > >> > >>> Am 17.01.2024 um 05:27 schrieb sergio ruiz <sergio.rrd@gmail.com>: > >>> > >>> Hi, all. > >>> > >>> One of my projects logs in to Spaces (Digital Ocean’s version of S3). I need to be able access the credentials, but I don’t want to store them in the source code, as I will be using Github to store the projects. > >>> > >>> Is there an accepted way to do this (encryption)? > >>> > >>> Should I store them on the system as environment variables? is this efficient? > >> > >> One of the usualy ways especially on unix systems is to hand credentials in via the process environment. If you execute > >> > >> OSEnvironment current at: ‚SHELL' > >> > >> in a playground you should see somthing like ‚/bin/bash‘. So when starting the process you just need to specify the environment variables so that pharo can access it. If you use docker there is a way to specify that easily. > >> > >> Norbert
JF
James Foster
Wed, Jan 17, 2024 2:48 PM

On Jan 17, 2024, at 3:55 AM, Norbert Hartl norbert@hartl.name wrote:

the example is about cloud servers. So we can rule out thumb drives easily ;) …

Norbert

I read the following to say that the goal is to talk to a cloud server from a non-cloud client.

One of my projects logs in to Spaces (Digital Ocean’s version of S3).

James

On Jan 17, 2024, at 3:55 AM, Norbert Hartl <norbert@hartl.name> wrote: > > the example is about cloud servers. So we can rule out thumb drives easily ;) … > > Norbert I read the following to say that the goal is to talk to a cloud server from a non-cloud client. > One of my projects logs in to Spaces (Digital Ocean’s version of S3). James