Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Comments on Running remote scripts (cloud scripts) locally --- valid and securely as possible

Parent

Running remote scripts (cloud scripts) locally --- valid and securely as possible

+1
−1

I use CentOS with Bash and I would like to download, execute and delete the executed downloaded file (running a remote/cloud script locally).

I often prefer to load my own shell scripts from my own GitHub account. I will normally do it for small shell scripts not exceeding approximately 25 code lines.


I tried to execute a remote script ending with a while true; do case esac done with:

wget -O - https://raw.githubusercontent.com/<username>/<project>/<branch>/<path>/<file> | bash

But then I had the problem of endless loop of echo in a case esac for some reason (CTRL+C stopped it) so I turned to a more "traditional" way of running remote scripts such as:

cd DESTINATION &&
wget https://raw.githubusercontent.com/<username>/<project>/<branch>/<path>/<file> &&
source FILENAME &&
rm FILENAME

How would you make that "traditional" code more validated? More secured?

An example for a current problem; the file downloaded can have a trivial name such as install.sh and collide with similar files (the rm is especially problematic here I think).

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.
Why should this post be closed?

1 comment thread

General comments (3 comments)
Post
+3
−0

An example for a current problem; the file downloaded can have a trivial name such as install.sh and collide with similar files (the rm is especially problematic here I think).

This is why tempfile exists.

FILENAME=`tempfile`
cd DESTINATION &&
wget -O ${FILENAME} https://raw.githubusercontent.com/<username>/<project>/<branch>/<path>/<file> &&
source ${FILENAME} &&
rm ${FILENAME}

If you really want the temp file to be in DESTINATION, you can change the invocation to tempfile -d DESTINATION.

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.

1 comment thread

General comments (3 comments)
General comments
deleted user wrote almost 4 years ago

Thank you Peter, about ${HOME} it was a mistake, I should have written DESTINATION or something like that. Thanks again,

deleted user wrote almost 4 years ago

Hello Peter, I have suggested an edit but maybe it wasn't saved or rejected? I don't have any notification and can't find any history. Please tell me if you rejected the edit... I have just tried to make the answer in line with my original intention (to write DESTINATION instead $HOME) and with my own question edit... Thanks,

Peter Taylor‭ wrote almost 4 years ago

@JohnDoea , I saw the proposed edit before the change to the question and it seemed to make the answer worse rather than better. I can apply the changes again though, fixing the typo.