I am just learning PGP as this has become a critical process at my job. I am currently manually encrypting/decrypting files with PGP and I would like to script this out but I am not seeing too much documentation on that type of process.
I got the command line to encrypt the files but it puts the files with a .gpg and I need it to be .pgp.
Here is what I have tried so far.
gpg -e -v -r name --output c:\temp\test*.txt.pgp c:\temp\test*.txt
This fails, but if I do gpg -e -v -r name --output c:\temp\test\test.txt.pgp c:\temp\test\test.txt, it works as designed.
The issue here is that I will have multiple files with different names but the same file extension so knowing the exact name is not going to happen until that file is created. As we are building out automation these files can range in the hundreds in the coming weeks. I am using Kleopatra and set the settings on there to pgp instead of gpg but it appears that setting does not apply to the command line.
Can anyone provide any suggestions? This is driving me nuts!
Nevermind, I figured it out. I am not sure why I didn't think of it sooner, perhaps I was focused in the gpg commandline. Anyhow, this can be done with PowerShell.
$files = Get-ChildItem "C:\temp\test"
ForEach($file in $files)
{
gpg -e -v -r great-west --output c:\temp\test\$file.pgp c:\temp\test\$file
}
The openssl man page says the "-pass pass:[password]" option for the openssl command is not secure because it's visible to utilities like ps, but is it secure through bash?
Like this:
#!/bin/bash
read -s psword
openssl enc -pass pass:$psword -aes-256-cbc -in text.plaintext -out text.encrypted
I've run a program like this on my computer and all ps seems to see is "openssl". Will other utilities be able to see the password?
The command line is normally easy in any operating system to get from any process normally. See this answer to getting a command line for a process. So it doesn't really matter what "starts" the process, be it bash or some custom application. This is the reason that that advise is given.
With any of these things it comes down to risk. If you accept the risk that it's not that secure then there is no reason not to use the command line (i.e. it's your machine and you are the only one using it). If lots of people can see your process sessions and possibility see a sensitive password then the risk may not be worth it. It's up to you to determine if the risk is acceptable.
if you want to secure the password, then its better to write it to a file that only your process has access to, and read the password from that file in your command. This will hide the plain password in the command line and make it invisible to other processes.
You can check the following answer. It is related to generating openssl keys but is similar to this topic:
How to generate an openSSL key using a passphrase from the command line?
I have a bash script and I want to use ncftp to do something. if I have this:
#!/bin/sh
HOST='my_IP_FTP_HOST'
USER='username'
PASSWD='password'
ncftp -u $USER -p $PASSWD $HOST <<END_SCRIPT
pwd
quit
END_SCRIPT
I get this error:
Syntax error in parameters or arguments
I don't understand why.
If I give it only the value and not the variables it works...
if I launch
$ sh -x script.sh
I get:
+ HOST=$'xxx.x.xx.xx\r'
+ USER=$'username\r'
+ PASSWD=$'password\r'
+ ncftp -u $'username\r' -p $'password\r' $'xxx.x.xx.xx\r'
NcFTP 3.2.1 (Jul 29, 2007) by Mike Gleason (http://www.NcFTP.com/contact/).
Welcome to FTP server
Syntax error in parameters or arguments
hmmm.... \r creates problems sure.
Are you editing this file on Microsoft Windows? It doesn't works because the original file uses Windows carriage returns, which are passed to variables and then to ncftp, which then halts.
Fix it by using another text editor, or by using dos2unix. Ideally you'd first use dos2unix once and then change the text editor.
Alternatively (but really, really not recommended) you could just parse the variables and remove the extra \r, like below, especially when the problem arises at some input reading, which doesn't seems to be the case here.
HOST=${HOST%\\r}
USER=${USER%\\r}
PASSWD=${PASSWD%\\r}
Take care when copying text from Windows, or when editing without appropriate software.
I have a bash script which uses a text file containing a list of logins:
LOGINLIST=/home/user/logins.txt
while read line
do
echo $line
done < $LOGINLIST
I'd rather not store the list of logins as plain text, but I don't want to have to manually decrypt it every time time I run the script. (Having the script prompt for a password would be OK.)
One way I could do this would be to include a line in the script where e.g openssl decrypts the file before it gets read. Unfortunately, if the script stalled (perhaps one of the sites it's logging in to isn't responding) this would leave the file unprotected for an indeterminate period of time.
So I'd rather keep the plaintext in memory only.
This post on LinuxQuestions ( http://www.linuxquestions.org/questions/programming-9/can-we-hide-the-code-of-a-shell-script-370328/#post1887648 ) suggests that sending the plaintext to a FIFO might do the trick, but that's wholly unfamiliar territory for me. Is there a better / simpler way? How do I wipe the memory when the script is done?
...and is there a way to edit the encrypted login list while also keeping the plaintext in memory?
You can do that with openssl and process substitution without changing the structure of your code.
To encrypt the file, use something like:
openssl blowfish -in plaint_text_file -out encrytped_file
(Choose the cipher you want, it will prompt you for a password.)
Then you can use the encrypted file with:
LOGINLIST=/path/to/encrypted/file
while read line
do
echo $line
done < <(openssl blowfish -d -in $LOGINLIST)
This will prompt you for the password. No temporary file generated.
(Careful with the spaces in the last command, it really is < <(.)
You can open an existing encrypted file named encrytped_file in vim with:
openssl blowfish -d -in encrytped_file | vim -
You can create or modify/overwrite an encrypted file named encrytped_file via vim with:
:w !openssl blowfish -in /dev/stdin -out encrytped_file
Just look for the password prompts. They will get obscured a bit by vim's ui.
Here are the tricks used in this answer. You should learn them rather than copy and paste them so that you can use them in other cases.
vim reads from a pipe (aka: stdin or standard input) when an argument of bare hyphen is given.
vim can pipe its buffer to a command with :w !command
It is very common for unix commands to interpret a bare hyphen as "read from standard input" but not all commands do. In this case, you can often use /dev/stdin
I would like to remove the digital signature from a Mac app that has been signed with codesign. There is an undocumented option to codesign, --remove-signature, which by it's name seems to be what I need. However, I can't get it to work. I realize it is undocumented, but I could really use the functionality. Maybe I'm doing something wrong?
codesign -s MyIdentity foo.app
works normally, signing the app
codesign --remove-signature foo.app
does disk activity for several seconds, then says
foo.app: invalid format for signature
and foo.app has grown to 1.9 GB!!! (Specifically, it is the executable in foo.app/Contents/Resources/MacOS that grows, from 1.1 MB to 1.9 GB.)
The same thing happens when I try to sign/unsign a binary support tool instead of a .app.
Any ideas?
Background: This is my own app; I'm not trying to defeat copy protection or anything like that.
I would like to distribute a signed app so that each update to the app won't need user approval to read/write the app's entries in the Keychain. However, some people need to modify the app by adding their own folder to /Resources. If they do that, the signature becomes invalid, and the app can't use it's own Keychain entries.
The app can easily detect if this situation has happened. If the app could then remove it's signature, everything would be fine. Those people who make this modification would need to give the modified, now-unsigned app permission to use the Keychain, but that's fine with me.
A bit late, but I've updated a public-domain tool called unsign which modifies executables to clear out signatures.
https://github.com/steakknife/unsign
I ran into this issue today. I can confirm that the --remove-signature option to Apple's codesign is (and remains, six years after the OP asked this question) seriously buggy.
For a little background, Xcode (and Apple's command line developer tools) include the codesign utility, but there is not included a tool for removing signatures. However, as this is something that needs to be done in certain situations pretty frequently, there is included a completely undocumented option:
codesign --remove-signature which (one assumes, given lack of documentation) should, well, be fairly self-explanatory but unfortunately, it rarely works as intended without some effort. So I ended up writing a script that should take care of the OP's problem, mine, and similar. If enough people find it here and find it useful, let me know and I'll put it on GitHub or something.
#!/bin/sh # codesign_remove_for_real -- working `codesign --remove-signature`
# (c) 2018 G. Nixon. BSD 2-clause minus retain/reproduce license requirements.
total_size(){
# Why its so damn hard to get decent recursive filesize total in the shell?
# - Darwin `du` doesn't do *bytes* (or anything less than 512B blocks)
# - `find` size options are completely non-standardized and doesn't recurse
# - `stat` is not in POSIX at all, and its options are all over the map...
# - ... etc.
# So: here we just use `find` for a recursive list of *files*, then wc -c
# and total it all up. Which sucks, because we have to read in every bit
# of every file. But its the only truly portable solution I think.
find "$#" -type f -print0 | xargs -0n1 cat | wc -c | tr -d '[:space:]'
}
# Get an accurate byte count before we touch anything. Zero would be bad.
size_total=$(total_size "$#") && [ $size_total -gt 0 ] || exit 1
recursively_repeat_remove_signature(){
# `codesign --remove-signature` randomly fails in a few ways.
# If you're lucky, you'll get an error like:
# [...]/codesign_allocate: can't write output file: [...] (Invalid argument)
# [...] the codesign_allocate helper tool cannot be found or used
# or something to that effect, in which case it will return non-zero.
# So we'll try it (suppressing stderr), and if it fails we'll just try again.
codesign --remove-signature --deep "$#" 2>/dev/null ||
recursively_repeat_remove_signature "$#"
# Unfortunately, the other very common way it fails is to do something? that
# hugely increases the binary size(s) by a seemingly arbitrary amount and
# then exits 0. `codesign -v` will tell you that there's no signature, but
# there are other telltale signs its not completely removed. For example,
# if you try stripping an executable after this, you'll get something like
# strip: changes being made to the file will invalidate the code signature
# So, the solution (well, my solution) is to do a file size check; once
# we're finally getting the same result, we've probably been sucessful.
# We could of course also use checksums, but its much faster this way.
[ $size_total == $(total_size "$#") ] ||
recursively_repeat_remove_signature "$#"
# Finally, remove any leftover _CodeSignature directories.
find "$#" -type d -name _CodeSignature -print0 | xargs -0n1 rm -rf
}
signature_info(){
# Get some info on code signatures. Not really required for anything here.
for info in "-dr-" "-vv"; do codesign $info "$#"; done # "-dvvvv"
}
# If we want to be be "verbose", check signature before. Un/comment out:
# echo >&2; echo "Current Signature State:" >&2; echo >&2; signature_info "$#"
# So we first remove any extended attributes and/or ACLs (which are common,
# and tend to interfere with the process here) then run our repeat scheme.
xattr -rc "$#" && chmod -RN "$#" && recursively_repeat_remove_signature "$#"
# Done!
# That's it; at this point, the executable or bundle(s) should sucessfully
# have truly become stripped of any code-signing. To test, one could
# try re-signing it again with an ad-hoc signature, then removing it again:
# (un/comment out below, as you see fit)
# echo >&2 && echo "Testing..." >&2; codesign -vvvvs - "$#" &&
# signature_info "$#" && recursively_repeat_remove_signature "$#"
# And of course, while it sometimes returns false positives, lets at least:
codesign -dvvvv "$#" || echo "Signature successfully removed!" >&2 && exit 0
Here's the source for codesign which lists all options, including those not covered by the command-line -h and man page.
Also, here is Apple's tech note on recent changes in how code-signing works
I agree that there's something strange going on when you did --remove-signature.
However, instead of trying to un-code-sign, you should change the way your user put extra files in the Resources. Instead, designate a certain path, usually
~/Library/Application Support/Name_Of_Your_App/
or maybe
~/Library/Application Support/Name_Of_Your_App/Resources/
and ask the user to put extra files there. Then, in your code, always check for the directory in addition to the files in the Resources when you need to read a file.
On a second reading of this question, another thought: perhaps a better approach to accomplish what the ultimate goal of the question is would be not to remove the signatures, but to have users (via a script/transparently) re-sign the app after modification, using an ad-hoc signature. That is, codesign -fs - [app], I believe. See https://apple.stackexchange.com/questions/105588/anyone-with-experience-in-hacking-the-codesigning-on-os-x