Hi All,

I need to Decrypt/Encrypt a file in the same name, but is this allowed ?

My project script is available in the Encrypted format . I need to perform the the following steps .

1. Decrypt the project file
2. Execute the the project by running the file
3. Encrypt the project file back

openssl enc -aes-256-cbc -pass pass:password -d -p -base64 -in ./run1.sh -out run1.sh
source ./run1.sh
openssl enc -aes-256-cbc -pass pass:password -p -base64 -in ./run1.sh -out ./run1.sh

Please suggest a solution for the above problem.

Thanks
Parth

In article <0fa2fc32-2190-4d0d-a554-2e753028b9ben@googlegroups.com>,
gpa...@gmail.com <gparthu@gmail.com> wrote:
>Hi All,
>
>I need to Decrypt/Encrypt a file in the same name, but is this allowed ?
>
>My project script is available in the Encrypted format . I need to perform the
>the following steps .
>
>1. Decrypt the project file
>2. Execute the the project by running the file
>3. Encrypt the project file back

I suppose that, as always, the first question to ask is: Why?
(I.e., what is wrong with using the solution you already have?)

Now, not saying that there aren't good aesthetic reasons for wanting to do
it "in place". In fact, I recently met up with this issue - where I had a
program that doesn't support "editing in place" and I wished that it did.
It is natural to note that some programs (sed, gawk) do support editing in
place, and wouldn't it be nice if they all did.

What I came up with was this, as a general solution:

$ ex -c '%!yourprogram -someOption "Quoted arg to someOption: $opt"' -c x $file

Or, another idea, could you just do:

$ yourDecryptionProgram -o /dev/stdout | sh

(I.e., not write out the decrypted text to a disk file at all)

--
Conservatives want smaller government for the same reason criminals want fewer cops.

In our last episode, the evil Dr. Lacto had captured our hero,
gpa...@gmail.com <gparthu@gmail.com>, who said:
> Hi All,
>
> I need to Decrypt/Encrypt a file in the same name, but is this allowed ?
>
> My project script is available in the Encrypted format . I need to perform the the following steps .
>
> 1. Decrypt the project file
> 2. Execute the the project by running the file
> 3. Encrypt the project file back
>
> openssl enc -aes-256-cbc -pass pass:password -d -p -base64 -in ./run1.sh -out run1.sh
> source ./run1.sh
> openssl enc -aes-256-cbc -pass pass:password -p -base64 -in ./run1.sh -out ./run1.sh

In most cases, you cannot guarantee that this process (using the same file
as both input and output) happens in a regular well-known well-supported
sequence.

Your best bet IMHO would be

openssl enc -aes-256-cbc -pass pass:password -d -p -base64 \
-in ./run1.sh -out run1a.sh
mv run1a.sh run1.sh
source ./run1.sh
openssl enc -aes-256-cbc -pass pass:password -p -base64 \
-in ./run1.sh -out ./run1a.sh
mv run1a.sh run1.sh

--hymie! http://nasalinux.net/~hymie hymie@nasalinux.net

"gpa...@gmail.com" <gparthu@gmail.com> writes:

> I need to Decrypt/Encrypt a file in the same name, but is this allowed?

Why do you need to? I know this the sort of answer people hate to get,
but it's generally a bad idea to try to do this.

> My project script is available in the Encrypted format . I need to
> perform the the following steps .
>
> 1. Decrypt the project file
> 2. Execute the the project by running the file

Technically you don't do this. "Sourcing" the file is not the same as
running it.

> 3. Encrypt the project file back
>
> openssl enc -aes-256-cbc -pass pass:password -d -p -base64 -in ./run1.sh -out run1.sh
> source ./run1.sh
> openssl enc -aes-256-cbc -pass pass:password -p -base64 -in ./run1.sh -out ./run1.sh
>
> Please suggest a solution for the above problem.

I would not store the decrypted file at all:

openssl enc -aes-256-cbc -pass pass:password -base64 -d \
-in ./run1.sh -out - | source /dev/stdin

and unless you really need to source it, I'd pass it to a shell:

openssl enc -aes-256-cbc -pass pass:password -base64 -d \
-in ./run1.sh -out - | sh

To address your original question, you can't use the file for the input
and the output, but you can use the same name provided you move one out
of the way. So move the source, decrypt to the old name and then remove
the source or decrypt to a new name and the rename it. This can lose
you your data unless you check the everything went well.

--
Ben.

On Fri, 21 May 2021 07:11:26 -0700 (PDT), "gpa...@gmail.com"
<gparthu@gmail.com> wrote:

> I need to Decrypt/Encrypt a file in the same name, but is this allowed ?
>
> My project script is available in the Encrypted format . I need to perform the the following steps .
>
> 1. Decrypt the project file
> 2. Execute the the project by running the file
> 3. Encrypt the project file back

> openssl enc -aes-256-cbc -pass pass:password -d -p -base64 -in ./run1.sh -out run1.sh
> source ./run1.sh
> openssl enc -aes-256-cbc -pass pass:password -p -base64 -in ./run1.sh -out ./run1.sh

You are allowed to do anything you like, but it might not work
to youre satisfaction.
If you "need to Decrypt/Encrypt a file in the same name" and the
tools can't do it, you are stuck.

What did you try? What were the results/prblems?

I would suggest something like:

mv -f ./run1.sh ./run1.aes
openssl enc -aes-256-cbc -pass pass:password \
-d -p -base64 -in ./run1.aes -out ./run1.sh
source ./run1.sh
openssl enc -aes-256-cbc -pass pass:password \
-p -base64 -in ./run1.sh -out ./run1.aes
mv -f ./run1.aes ./run1.sh

or similar constructs.
--
Kees Nuyt

On Friday, May 21, 2021 at 8:38:28 PM UTC+5:30, Ben Bacarisse wrote:
> "gpa...@gmail.com" <gpa...@gmail.com> writes:
>
> > I need to Decrypt/Encrypt a file in the same name, but is this allowed?
> Why do you need to? I know this the sort of answer people hate to get,
> but it's generally a bad idea to try to do this.
> > My project script is available in the Encrypted format . I need to
> > perform the the following steps .
> >
> > 1. Decrypt the project file
> > 2. Execute the the project by running the file
> Technically you don't do this. "Sourcing" the file is not the same as
> running it.
> > 3. Encrypt the project file back
> >
> > openssl enc -aes-256-cbc -pass pass:password -d -p -base64 -in ./run1.sh -out run1.sh
> > source ./run1.sh
> > openssl enc -aes-256-cbc -pass pass:password -p -base64 -in ./run1.sh -out ./run1.sh
> >
> > Please suggest a solution for the above problem.
> I would not store the decrypted file at all:
>
> openssl enc -aes-256-cbc -pass pass:password -base64 -d \
> -in ./run1.sh -out - | source /dev/stdin
>
> and unless you really need to source it, I'd pass it to a shell:
>
> openssl enc -aes-256-cbc -pass pass:password -base64 -d \
> -in ./run1.sh -out - | sh
>
> To address your original question, you can't use the file for the input
> and the output, but you can use the same name provided you move one out
> of the way. So move the source, decrypt to the old name and then remove
> the source or decrypt to a new name and the rename it. This can lose
> you your data unless you check the everything went well.
>
> --
> Ben.

Hi Experts,

Thanks a lot for the above solution and worked well.
For generic scripts (.tcl, .sh) which are run in shell and not used in any EDA tool flow , it worked well.
(decrypting on the fly without storing, it on disk pass it to a shell)

Now, to use it same procedure in an EDA tool environment, how can we handle the scenario of decrypt and run a tool run command in the shell ?
EDA tool specific commands to be run in shell as shown below where run1.tcl.aes is an encrypted file

/tools/bin/vivado -mode batch -source run1.tcl.aes

Best Regards
Parth

"gpa...@gmail.com" <gparthu@gmail.com> writes:

> On Friday, May 21, 2021 at 8:38:28 PM UTC+5:30, Ben Bacarisse wrote:

>> I would not store the decrypted file at all:
>>
>> openssl enc -aes-256-cbc -pass pass:password -base64 -d \
>> -in ./run1.sh -out - | source /dev/stdin
>>
>> and unless you really need to source it, I'd pass it to a shell:
>>
>> openssl enc -aes-256-cbc -pass pass:password -base64 -d \
>> -in ./run1.sh -out - | sh

> Thanks a lot for the above solution and worked well.
> For generic scripts (.tcl, .sh) which are run in shell and not used in
> any EDA tool flow , it worked well. (decrypting on the fly without
> storing, it on disk pass it to a shell)
>
> Now, to use it same procedure in an EDA tool environment, how can we
> handle the scenario of decrypt and run a tool run command in the shell
> ?

I've no idea what an EDA tool environment is. Unix/Linux tools are
often designed to work as part of a pipeline. Maybe EDA tools are not?

> EDA tool specific commands to be run in shell as shown below where
> run1.tcl.aes is an encrypted file
>
> /tools/bin/vivado -mode batch -source run1.tcl.aes

It all depends on what this program (about which I know nothing) is
doing an how it goes about doing it.

At a guess, I'd try

openssl enc -d ...other options... -in ./run1.sh -out - |\
/tools/bin/vivado -mode batch -source /dev/stdin

Does vivado have a man page? I.e. what does "man vivado" say once
you've installed whatever it is that this program is part of?

--
Ben.

On Thursday, June 17, 2021 at 1:48:41 AM UTC+5:30, Ben Bacarisse wrote:
> "gpa...@gmail.com" <gpa...@gmail.com> writes:
>
> > On Friday, May 21, 2021 at 8:38:28 PM UTC+5:30, Ben Bacarisse wrote:
>
> >> I would not store the decrypted file at all:
> >>
> >> openssl enc -aes-256-cbc -pass pass:password -base64 -d \
> >> -in ./run1.sh -out - | source /dev/stdin
> >>
> >> and unless you really need to source it, I'd pass it to a shell:
> >>
> >> openssl enc -aes-256-cbc -pass pass:password -base64 -d \
> >> -in ./run1.sh -out - | sh
> > Thanks a lot for the above solution and worked well.
> > For generic scripts (.tcl, .sh) which are run in shell and not used in
> > any EDA tool flow , it worked well. (decrypting on the fly without
> > storing, it on disk pass it to a shell)
> >
> > Now, to use it same procedure in an EDA tool environment, how can we
> > handle the scenario of decrypt and run a tool run command in the shell
> > ?
> I've no idea what an EDA tool environment is. Unix/Linux tools are
> often designed to work as part of a pipeline. Maybe EDA tools are not?
> > EDA tool specific commands to be run in shell as shown below where
> > run1.tcl.aes is an encrypted file
> >
> > /tools/bin/vivado -mode batch -source run1.tcl.aes
> It all depends on what this program (about which I know nothing) is
> doing an how it goes about doing it.
>
> At a guess, I'd try
>
> openssl enc -d ...other options... -in ./run1.sh -out - |\
> /tools/bin/vivado -mode batch -source /dev/stdin
>
> Does vivado have a man page? I.e. what does "man vivado" say once
> you've installed whatever it is that this program is part of?
>
> --
> Ben.

Required vivado synthesis command is "vivado -mode batch -source run1.tcl" where vivado looks for a tcl file as input in batch mode.

vivado [-mode <arg>] [-init] [-source <arg>] [-nojournal] [-appjournal],
[-journal <arg>] [-nolog] [-applog] [-log <arg>] [-version]
[-tclargs <arg>] [-tempDir <arg>] [-robot <arg>] [-verbose] [<project>]

Usage:
Name Description
--------------------------
[-mode] Invocation mode, allowed values are 'gui', 'tcl', and 'batch' Default: gui
[-source] Source the specified Tcl file
[-nojournal] Do not create a journal file
[-journal] Journal file name Default: vivado.jou
[-nolog] Do not create a log file
[-applog] Open log file in append mode
[-log] Log file name
[-tclargs] Arguments passed on to tcl argc argv
[-tempDir] Temporary directory name.

"gpa...@gmail.com" <gparthu@gmail.com> writes:

> On Thursday, June 17, 2021 at 1:48:41 AM UTC+5:30, Ben Bacarisse wrote:
>> "gpa...@gmail.com" <gpa...@gmail.com> writes:
>>
>> > On Friday, May 21, 2021 at 8:38:28 PM UTC+5:30, Ben Bacarisse wrote:
>>
>> >> I would not store the decrypted file at all:
>> >>
>> >> openssl enc -aes-256-cbc -pass pass:password -base64 -d \
>> >> -in ./run1.sh -out - | source /dev/stdin
>> >>
>> >> and unless you really need to source it, I'd pass it to a shell:
>> >>
>> >> openssl enc -aes-256-cbc -pass pass:password -base64 -d \
>> >> -in ./run1.sh -out - | sh
>> > Thanks a lot for the above solution and worked well.
>> > For generic scripts (.tcl, .sh) which are run in shell and not used in
>> > any EDA tool flow , it worked well. (decrypting on the fly without
>> > storing, it on disk pass it to a shell)
>> >
>> > Now, to use it same procedure in an EDA tool environment, how can we
>> > handle the scenario of decrypt and run a tool run command in the shell
>> > ?
>> I've no idea what an EDA tool environment is. Unix/Linux tools are
>> often designed to work as part of a pipeline. Maybe EDA tools are not?
>> > EDA tool specific commands to be run in shell as shown below where
>> > run1.tcl.aes is an encrypted file
>> >
>> > /tools/bin/vivado -mode batch -source run1.tcl.aes
>> It all depends on what this program (about which I know nothing) is
>> doing an how it goes about doing it.
>>
>> At a guess, I'd try
>>
>> openssl enc -d ...other options... -in ./run1.sh -out - |\
>> /tools/bin/vivado -mode batch -source /dev/stdin
>>
>> Does vivado have a man page? I.e. what does "man vivado" say once
>> you've installed whatever it is that this program is part of?
>>
> Required vivado synthesis command is "vivado -mode batch -source
> run1.tcl" where vivado looks for a tcl file as input in batch mode.
>
> vivado [-mode <arg>] [-init] [-source <arg>] [-nojournal] [-appjournal],
> [-journal <arg>] [-nolog] [-applog] [-log <arg>] [-version]
> [-tclargs <arg>] [-tempDir <arg>] [-robot <arg>] [-verbose] [<project>]
>
> Usage:
> Name Description
> --------------------------
> [-mode] Invocation mode, allowed values are 'gui', 'tcl', and 'batch' Default: gui
> [-source] Source the specified Tcl file
> [-nojournal] Do not create a journal file
> [-journal] Journal file name Default: vivado.jou
> [-nolog] Do not create a log file
> [-applog] Open log file in append mode
> [-log] Log file name
> [-tclargs] Arguments passed on to tcl argc argv
> [-tempDir] Temporary directory name.

This adds almost no useful information (that's not your fault!). Did my
guess work or not?

--
Ben.

On Thursday, June 17, 2021 at 4:06:46 PM UTC+5:30, Ben Bacarisse wrote:
> "gpa...@gmail.com" <gpa...@gmail.com> writes:
>
> > On Thursday, June 17, 2021 at 1:48:41 AM UTC+5:30, Ben Bacarisse wrote:
> >> "gpa...@gmail.com" <gpa...@gmail.com> writes:
> >>
> >> > On Friday, May 21, 2021 at 8:38:28 PM UTC+5:30, Ben Bacarisse wrote:
> >>
> >> >> I would not store the decrypted file at all:
> >> >>
> >> >> openssl enc -aes-256-cbc -pass pass:password -base64 -d \
> >> >> -in ./run1.sh -out - | source /dev/stdin
> >> >>
> >> >> and unless you really need to source it, I'd pass it to a shell:
> >> >>
> >> >> openssl enc -aes-256-cbc -pass pass:password -base64 -d \
> >> >> -in ./run1.sh -out - | sh
> >> > Thanks a lot for the above solution and worked well.
> >> > For generic scripts (.tcl, .sh) which are run in shell and not used in
> >> > any EDA tool flow , it worked well. (decrypting on the fly without
> >> > storing, it on disk pass it to a shell)
> >> >
> >> > Now, to use it same procedure in an EDA tool environment, how can we
> >> > handle the scenario of decrypt and run a tool run command in the shell
> >> > ?
> >> I've no idea what an EDA tool environment is. Unix/Linux tools are
> >> often designed to work as part of a pipeline. Maybe EDA tools are not?
> >> > EDA tool specific commands to be run in shell as shown below where
> >> > run1.tcl.aes is an encrypted file
> >> >
> >> > /tools/bin/vivado -mode batch -source run1.tcl.aes
> >> It all depends on what this program (about which I know nothing) is
> >> doing an how it goes about doing it.
> >>
> >> At a guess, I'd try
> >>
> >> openssl enc -d ...other options... -in ./run1.sh -out - |\
> >> /tools/bin/vivado -mode batch -source /dev/stdin
> >>
> >> Does vivado have a man page? I.e. what does "man vivado" say once
> >> you've installed whatever it is that this program is part of?
> >>
> > Required vivado synthesis command is "vivado -mode batch -source
> > run1.tcl" where vivado looks for a tcl file as input in batch mode.
> >
> > vivado [-mode <arg>] [-init] [-source <arg>] [-nojournal] [-appjournal],
> > [-journal <arg>] [-nolog] [-applog] [-log <arg>] [-version]
> > [-tclargs <arg>] [-tempDir <arg>] [-robot <arg>] [-verbose] [<project>]
> >
> > Usage:
> > Name Description
> > --------------------------
> > [-mode] Invocation mode, allowed values are 'gui', 'tcl', and 'batch' Default: gui
> > [-source] Source the specified Tcl file
> > [-nojournal] Do not create a journal file
> > [-journal] Journal file name Default: vivado.jou
> > [-nolog] Do not create a log file
> > [-applog] Open log file in append mode
> > [-log] Log file name
> > [-tclargs] Arguments passed on to tcl argc argv
> > [-tempDir] Temporary directory name.
> This adds almost no useful information (that's not your fault!). Did my
> guess work or not?
>
> --
> Ben.

No, it didn't work.

openssl enc -aes-256-cbc -pass pass:password -base64 -d -in ./run1.tcl.encr -out - | vivado -mode batch -source /dev/stdin

above command fails with the following error

source /dev/stdin
INFO: [Common 17-206] Exiting Vivado at Thu Jun 17 18:12:49 2021...

"gpa...@gmail.com" <gparthu@gmail.com> writes:

> On Thursday, June 17, 2021 at 4:06:46 PM UTC+5:30, Ben Bacarisse wrote:
>> "gpa...@gmail.com" <gpa...@gmail.com> writes:
>>
>> > On Thursday, June 17, 2021 at 1:48:41 AM UTC+5:30, Ben Bacarisse wrote:
>> >> "gpa...@gmail.com" <gpa...@gmail.com> writes:
>> >>
>> >> > On Friday, May 21, 2021 at 8:38:28 PM UTC+5:30, Ben Bacarisse wrote:
>> >>
>> >> >> I would not store the decrypted file at all:
>> >> >>
>> >> >> openssl enc -aes-256-cbc -pass pass:password -base64 -d \
>> >> >> -in ./run1.sh -out - | source /dev/stdin
>> >> >>
>> >> >> and unless you really need to source it, I'd pass it to a shell:
>> >> >>
>> >> >> openssl enc -aes-256-cbc -pass pass:password -base64 -d \
>> >> >> -in ./run1.sh -out - | sh
>> >> > Thanks a lot for the above solution and worked well.
>> >> > For generic scripts (.tcl, .sh) which are run in shell and not used in
>> >> > any EDA tool flow , it worked well. (decrypting on the fly without
>> >> > storing, it on disk pass it to a shell)
>> >> >
>> >> > Now, to use it same procedure in an EDA tool environment, how can we
>> >> > handle the scenario of decrypt and run a tool run command in the shell
>> >> > ?
>> >> I've no idea what an EDA tool environment is. Unix/Linux tools are
>> >> often designed to work as part of a pipeline. Maybe EDA tools are not?
>> >> > EDA tool specific commands to be run in shell as shown below where
>> >> > run1.tcl.aes is an encrypted file
>> >> >
>> >> > /tools/bin/vivado -mode batch -source run1.tcl.aes
>> >> It all depends on what this program (about which I know nothing) is
>> >> doing an how it goes about doing it.
>> >>
>> >> At a guess, I'd try
>> >>
>> >> openssl enc -d ...other options... -in ./run1.sh -out - |\
>> >> /tools/bin/vivado -mode batch -source /dev/stdin
>> >>
>> >> Does vivado have a man page? I.e. what does "man vivado" say once
>> >> you've installed whatever it is that this program is part of?
>> >>
>> > Required vivado synthesis command is "vivado -mode batch -source
>> > run1.tcl" where vivado looks for a tcl file as input in batch mode.
>> >
>> > vivado [-mode <arg>] [-init] [-source <arg>] [-nojournal] [-appjournal],
>> > [-journal <arg>] [-nolog] [-applog] [-log <arg>] [-version]
>> > [-tclargs <arg>] [-tempDir <arg>] [-robot <arg>] [-verbose] [<project>]
>> >
>> > Usage:
>> > Name Description
>> > --------------------------
>> > [-mode] Invocation mode, allowed values are 'gui', 'tcl', and 'batch' Default: gui
>> > [-source] Source the specified Tcl file
>> > [-nojournal] Do not create a journal file
>> > [-journal] Journal file name Default: vivado.jou
>> > [-nolog] Do not create a log file
>> > [-applog] Open log file in append mode
>> > [-log] Log file name
>> > [-tclargs] Arguments passed on to tcl argc argv
>> > [-tempDir] Temporary directory name.
>> This adds almost no useful information (that's not your fault!). Did my
>> guess work or not?
>>
>
> No, it didn't work.
>
> openssl enc -aes-256-cbc -pass pass:password -base64 -d -in ./run1.tcl.encr -out - | vivado -mode batch -source /dev/stdin
>
> above command fails with the following error
>
> source /dev/stdin
> INFO: [Common 17-206] Exiting Vivado at Thu Jun 17 18:12:49 2021...

I thought error codes went out of fashion in the 1970s! What is error
Common 17-206?

Anyway, maybe vivado needs a seekable input in which case it won't ever
work. It certainly does not appear to be written as a Unix-like tool.

You may have to store the un-encrypted source as a file. How sensitive
are the contents? If they are very sensitive, even a pipe is not really
safe.

--
Ben.