Re: how do I hide a variable from viewing

[email protected] (ToddAndMargo via perl6-users) Wed, 21 May 2025 14:51:28 -0700
Newsgroups perl.perl6.users
Message-ID <[email protected]>
On 5/21/25 5:02 AM, Peter Pentchev wrote:
> On Tue, May 20, 2025 at 10:10:06PM -0700, ToddAndMargo via perl6-users wrote:
>>>> *From:* ToddAndMargo via perl6-users <[email protected]>
>>>> *Sent:* Tuesday, May 20, 2025 5:29 AM
>>>> *To:* perl6-users <[email protected]>
>>>> *Subject:* how do I hide a variable from viewing
>>>> Hi All,
>>>>
>>>> Fedora 41 (Linux)
>>>>
>>>> Since my *.raku can be publicly read, how do I obscure
>>>> the contents of a variable so other can not read it?
>>>>
>>>> Currently what I have been doing is setting the file's
>>>> ownership to root:root and the attributes to 700 so
>>>> only root can see it.
>>>>
>>>> I would be nice to obscure a variable inside the
>>>> program though.
>>
>> On 5/20/25 4:44 AM, Mark Devine wrote:
>>> Todd,
>>>
>>> I got tired of having clear-text passwords and other sensitive strings
>>> in my raku scripts, so I wrote KHPH for myself for use on Linux/UNIX,
>>> then published it.  The idea catches criticism because it isn't
>>> encryption, but rather just a little obfuscation.  Sometimes a little
>>> obfuscation is warranted, imo.
>>>
>>> It takes a string, then mangles it into an unrecognizable scrambled
>>> form, stashes it in a file, then can be recalled/unscrambled later.
>>>
>>> https://github.com/markldevine/raku-KHPH <https://github.com/
>>> markldevine/raku-KHPH>
>>> <https://github.com/markldevine/raku-KHPH>
>>> 	
>>> markldevine/raku-KHPH: Keep Honest People Honest - GitHub <https://
>>> github.com/markldevine/raku-KHPH>
>>> Keep Honest People Honest - String Obfuscation, Storage, & Retrieval -
>>> markldevine/raku-KHPH
>>> github.com
>>>
>>> Maybe you'll find it useful, but maybe only on Linux/UNIX.
>>>
>>> use KHPH; KHPH.new(:stash-path('/tmp/.myapp/password.khph')).expose.print;
>>>
>>>    *
>>>      or -
>>>
>>>
>>> use KHPH;
>>> my $passowrd = KHPH.new(:stash-path($*HOME ~ '/.rakucache/myapp/
>>> password.khph'));
>>> # $password.expose will unscramble the string, so you can substitute it
>>> where you need to
>>
>> Hi Mark,
>>
>> I have written something similar.  Without the seed and
>> the start point, it is (although never say never)
>> impossible to decrypt it.
>>
>> My issue is, unlike a fully compiled code, if a bad guy
>> has access to my Raku code, which is necessary to run
>> the program, he also has access to the seed and
>> the start point, plus the encryption and decryption
>> module.
>>
>> I was thinking maybe there is a way to only present the
>> binary of my code, like a fully compiled code?  Or maybe
>> some way to obscure something inside my Raku code?
>>
>> Thank you for the help!
> 
> The usual way to do this is to make the program read a configuration
> file that contains any credentials necessary. Lately I've been
> a big fan of the TOML format for config files, mostly because
> the "standard" INI-style files are not standard at all, not even
> under different versions of the same operating system :)
> 
> But the general idea is:
> - the program, on startup, looks for a configuration file in
>    a place where such things are kept (this part is OS-dependent, but
>    there are ways to do it more or less platform-independently;
>    I think for Raku the XDG::BaseDirectory module would help)
> - the program reads the config file and exits if it doesn't contain
>    the necessary credentials (username, password, URLs, whatever)
> - now it is the user's and the system administrator's responsibility
>    (as it should be) to protect that config file as much as it is
>    appropriate for that specific machine/installation
> 
> Hope that helps!
> 
> G'luck,
> Peter
> 

In Bash, you load the INI file with `. file.ini`.
What it does is load all the variables into the
running bash program.   The ini format is identical
to the variable creation format in side bash
      Network=192.168.1.1
Windows I am not so sure about.

I have been using root:root as the ownership and 700
as the permissions.

I occurs to me if the bad guys have root access, then
access to an INI file or my code would be the absolute
least of my problems.  And with root access, the bad
guys would probably lose all interest in an smtp
password that I encrypted and be planting malicious
code and stealing data.

Would you give me a link to the "TOML format".  It sound
interesting.

Thank you for the help!
-T