On Wed, May 21, 2025 at 02:51:28PM -0700, ToddAndMargo via perl6-users wrote: > 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 <perl6-us...@perl.org> > > > > > *Sent:* Tuesday, May 20, 2025 5:29 AM > > > > > *To:* perl6-users <perl6-us...@perl.org> > > > > > *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
Errr... no. When you do '. file.ini', you are NOT telling the shell to read an INI-style file, you are telling it to EXECUTE shell commands. When you do '. file.ini', what happens is that the shell (in your case, Bash) will read 'file.ini' and execute it as a shell script. It does not treat it as a file that contains some kind of variables and values, it treats it as a shell script. This has several important consequences: - if the file contains anything other than var=value lines, the shell will execute that "other" thing as commands; when you do '. file.ini', the shell will execute any commands it finds there - even if there are only var=value lines, if any of them contains $VARNAME (not hidden within single quotes), then the shell shall substitute the value of the environment variable "VARNAME" there - if any of the lines contain `...` or $(...), the shell will, once again, execute the commands within - the shell will interpret single and double quotes as per its own grammar and most probably not present them to the program that sourced the file - on a var=value line, a "#" character outside of single or double quotes will cause the rest of the line to be ignored as a comment All of these, along with a couple of other things (line continuation, "#" or ";" characters as comments, etc) are very, very important differences between shell programs (which is what you tell the shell 'file.ini' is when you source it using the '.' builtin command) and INI-style files. When you do '. file.ini', you are NOT telling the shell to read an INI-style file, you are telling it to EXECUTE shell commands. > 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. That is pretty much exactly what I meant. If the attacker has enough rights to read the properly-protected configuration file, they have enough rights to do other stuff, too. > Would you give me a link to the "TOML format". It sound > interesting. The format itself is described at https://toml.io/en/ There are libraries for reading and writing TOML files in all of the popular programming languages. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org pe...@morpheusly.com PGP key: https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
