Windows 7, GnuPG 2.1.19
I'm having a hell of time trying to automate decryption of files using GPG. I've tried all of the variations that I can find to pass the passphrase to the command line, but all continue to prompt me via the pop-up box. And, yes, I understand the security implications of including the passphrase in the command line, passphrase file, batch file, etc. Apparently, most people can get this to work:
echo mypassphrase| gpg --batch --output test.csv --passphrase-fd 0 --decrypt test.csv.pgp
I've tried using the --passphrase-file switch. I've tried using --passphrase mypassphrase. I've tried various spacing and quoting variations. I'm pulling my hair out here. Thanks for any tips!
I resolved this problem on my own. I found that in version 2.1x of GnuPG, you have to add the "--pinentry-mode loopback" option and value.
Related
I'm running ubuntu 1804 on windows using the WSL. Everything is set up fine and works correctly. I've also installed ZSH and oh-my-zsh, again this is all good and everything looks like its working fine. Everything except the arrow keys whilst using vim or man pages or some other command line tools.
The up and down keys work on the command line when scrolling through history and also for select commands like nano. Also if I boot into bash rather than zsh the arrow keys do work in vim and man pages, in fact they work everywhere.
If i boot into bash, then switch to zsh on the command line manually the arrow keys then work everywhere.
So my cmder config for zsh
c:/_distros/ubuntu1804/ubuntu1804.exe -c zsh -cur_console:pm
and for bash
set "PATH=%ConEmuBaseDirShort%\wsl;%PATH%" & %ConEmuBaseDirShort%\conemu-cyg-64.exe --wsl -cur_console:pm:/mnt
The one for bash uses the conemu-cyg-64.exe program that comes from conemu which is a symbiont of POSIX enabled pty and WinAPI full-featured terminal.
Apparently you can use this tool with zsh but i cant manage to make it work i get the error
{PID:10592} failed to run shell (2): No such file or directory
{PID:10592} shell: `/usr/bin/zsh` `-l` `-i`
{PID:10592} dir: `/cygdrive/c/Program Files/cmder`
ConEmuC: Root process was alive less than 10 sec, ExitCode=0.
Press Enter or Esc to close console...
and this is the task in cmder
set "PATH=%ConEmuBaseDirShort%\wsl;%PATH%" & %ConEmuBaseDirShort%\conemu-cyg-64.exe /usr/bin/zsh -l -i -cur_console:pm:/mnt
So I think that if i can boot into zsh using conemu-cyg-64 that the cursor keys will probably work in commands like vim and the man pages. Any help or advice getting that working would be brilliant.
EDIT:
On my ubuntu install zsh is installed at /usr/bin/zsh, but there is no file or folder /cygdrive/c/Program Files/cmder
Many thanks to #Maximus for pointing me in the right direction. The answer was right under my nose at the bash on windows page of conemu. A small change to the command i was using before. the zsh needs to go on the end rather than before the --wsl.
The correct task to ensure that cursor keys work on all apps in the terminal is:
set "PATH=%ConEmuBaseDirShort%\wsl;%PATH%" & %ConEmuBaseDirShort%\conemu-cyg-64.exe --wsl -cur_console:pnm:/mnt -t zsh -l
I need to reduce the size of nginx when compiled with openssl on an embedded target.
I am able to compile the nginx with ssl using the steps given in the http://wiki.nginx.org/InstallOptions. It compiles well, but the problem I am facing its size, i.e nginx binary coming to almost 6MB.
Since I have to run the nginx on the embedded target, I tried cross compiling with for arm based board. I am to cross compile and the size is coming to 1.3MB for the target.
If I disable openssl and compile its coming to 400KB, I think nginx is statically linking the openssl .
If so how to dynamically include the openssl to nginx, because my target libs already has the support for crypto and ssl libs. I tried all the option but could not succeeded.
If so how to dynamically include the openssl to nginx
You need to specify OpenSSL with:
--with-http_ssl_module
The above command will effective link against the OpenSSL shared object if available.
ngingx can also build OpenSSL for you with:
--with-openssl
I seem to recall some problems with --with-openssl (but I think they were related to the FIPS Capable OpenSSL Library).
To be certain you link against the shared object, you can run the following script on the nginx sources:
OPENSSL_INSTALL_DIR=/usr/local/ssl
OPENSSL_LIB_DIR="$OPENSSL_INSTALL_DIR/lib"
...
for FILE in "auto/lib/sha1/conf" "auto/lib/md5/conf" "auto/lib/openssl/conf"
do
TFILE=`mktemp /tmp/fix.XXXXXXXXXX`
sed -e "s|-lssl|$OPENSSL_LIB_DIR/libssl.so|g" "$FILE" > "$TFILE"
mv "$TFILE" "$FILE"
TFILE=`mktemp /tmp/fix.XXXXXXXXXX`
sed -e "s|-lcrypto|$OPENSSL_LIB_DIR/libcrypto.so|g" "$FILE" > "$TFILE"
mv "$TFILE" "$FILE"
done
That will ensure the linker links against a specific OpenSSL, and not just the one it finds (I've had a lot of trouble with -L, -l, -static and -shared in the past when cross compiling).
nginx binary coming to almost 6MB.
...
and the size is coming to 1.3MB for the target.
I'm not sure how small the size can get with OpenSSL present. The following may (or may not) reduce it further.
If you compile and link with the static archive, then you also have some compiler and linker options available to you. Specifically, you can discard unused functions with gc-sections:
--with-cc-opt="-ffunction-sections -fdata-sections"
--with-ld-opt="-Wl,--gc-sections"
You also have the strip option. You can run strip -s on the final binary or pass it to the linker though options:
--with-ld-opt="-Wl,-s"
See ld(1) and --strip-debug and --strip-all options.
-Bsymbolic might also help by reducing an ELF section size (I think its either the GOT or PLT, but I don't recall at the moment).
I used an encrypted file to store my passwords for years. It has been encrypted using the vi -x command on Sun Solaris 10. I now tried to open the file on a linux box with bothvi -x and vi -x -cm=blowfish. Sadly the file is completely messed up. My guess is that a different encryption algorithm has been used on Solaris. How can I find out which algorithm has been used and how can I open the file with a more recent version of vi?
I do know the correct password and I do know several words in the encrypted file.
P.S.: I do not have any access to a solaris 10 Machine anymore
I think vi uses the crypt function. This is a long shot, but if you have access to mcrypt, this should decode solaris crypt:
mcrypt -a des --keymode pkdes --bare --noiv --decrypt filename
old unix style crypt
mcrypt -a enigma --keymode scrypt --bare --decrypt filename
/usr/bin/vi (also linked from /usr/ucb/vi), /usr/xpg4/bin/vi, and /usr/xpg6/bin/vi on Solaris 10 (and such of those as were on all earlier versions of Solaris) all used crypt(1) (Enigma variant) encryption.
On Solaris 11 and later, vi is actually vim, and uses whatever encryption that version of vim supports, which is NOT compatible with crypt(1).
"Old" vi may still be on Solaris 11 as /usr/sunos/bin/vi, but does not have the -x option any more.
crypt(1) is also no longer on Solaris 11.
But one can easily scrounge the source (google for usr/src/cmd/crypt/crypt.c) and fix up whatever version one finds to compile ok.
And as a previous poster indicated, mcrypt can do the job too.
The latter is available for Macs via (at least) MacPorts ("port install mcrypt" although a trivial test of running mcrypt there didn't work for me), for CentOS via "yum install mcrypt", for Ubuntu via "apt install mcrypt"; cygwin also has an mcrypt package.
For any other OS or distro, you're on your own; I don't have everything. đ
I just started using Zsh lately for some of the integrated support in the shell prompt for my Git status etc.
When I type in:
ruby -v
to confirm the version of ruby I'm running, Zsh asks if I want to change the command to _ruby. Well after saying no at the prompt and the command completing as expected I continue to get the question at the prompt after confirming my command is correct.
I'm assuming there is a completion file or something of the sort.
Thanks
Update:
The shell is no longer trying to complete _ruby, it stopped responding after closing the shell a few times some how.
I tried to clean the file up several times but there is a "opts" variable that is 50 or more lines long and the lines are all ran together, some lines more than 150 characters. Maybe I could email an attachment to you if you still want to see it.
I sincerely apologize for the messy post.
This is command autocorrection, activated by the correct option. It has nothing to do with completion. You're seeing _ruby because zsh thinks there is no ruby command and it offers _ruby as the nearest existing match.
If you've just installed ruby, it's possible that zsh has memorized the list of available command earlier, and it won't always try to see if the command has appeared in between. In that case, run hash -rf. Future zsh sessions won't have this problem since the ruby command already existed when they started.
Sometimes, when you change your PATH, zsh forgets some hashed commands. The option hash_listall helps against this. As above, if you can force zsh to refresh its command cache with hash -rf.
You could make an alias:
alias ruby='nocorrect ruby'
It's what I did when zsh kept asking me if I meant .meteor when I typed meteor because auto-correct is still useful from time to time.
I find the autocorrect feature can get annoying at times. So I do in my ~/.zshrc,
DISABLE_CORRECTION="true"
I had the same problem even when the command is not installed.
I can solve it using the CORRECT_IGNORE variable in my .zshrc
# OPTs to enable
setopt HASH_LIST_ALL
setopt CORRECT
# Zsh variable to determine what to ignore,
# in this case everything starting with _ or .
CORRECT_IGNORE="[_|.]*"
I hope it helps to you or anyone with this issue
Sometime ago after an update, I got command auto-correction enabled which I don't want. If the same happened to you and you want to revert it, in the ~/.zshrc file you'll have make it:
# Uncomment the following line to enable command auto-correction.
ENABLE_CORRECTION="false"
or comment it as per bellow:
# Uncomment the following line to enable command auto-correction.
# ENABLE_CORRECTION="true"
Just a note, on my zsh (version 5.7.1 on macOS), the DISABLE_CORRECTION didn't work.
I saw in my .zshrc file the following two lines, which I then commented out
setopt CORRECT
setopt CORRECT_ALL
That did it for me.
as an replacement for ksh under cygwin, pdksh might be the only choice. but look like there have a bug for cygwin : pdksh(5.2.14-3) to support backslash path (\).
it will swallow the \ :
$ cd .\access
pdksh: cd: /cygdrive/e/.access - No such file or directory
After search on the internet, the same problem solved for other platform. but no idea how to solve it for cygwin.
Pdksh, like all Cygwin programs, does support backslashes as directory separators. But you have to quote them properly. Running shell scripts under Cygwin really teaches you to quote things properly, in particular to always put variable substitutions in double quotes, and not use echo carelessly (printf "%s" "$x" is portable and reliable: unlike echo, there's no risk that it might do backslash expansion).
Note that pdksh's compatibility with even ksh88 is far from perfect, so some scripts may fail for other reasons (such as relying on the status code of writer | reader being that of reader, which is the case in true ksh but not in pdksh). Cygwin includes zsh, which after you run emulate ksh is mostly compatible with ksh88 (though still not perfect).
There are non-Cygwin ports of ksh for Windows, including InterixSFUSUA and ATT's own port.
You have to use forward slashes, or double all the backslashes, or single-quote every string that might be a pathname. Sorry, there's no way around this. This is a general problem with trying to use Unix shells, for which \ is an escape character, on Windows.
From the Cygwin User's Guide:
Note
The usage of Win32 paths, though possible, is deprecated, since it circumvents important internal path handling mechanisms. See the section called âUsing native Win32 pathsâ and the section called âUsing the Win32 file API in Cygwin applicationsâ for more information.
There is a utility called cygpath that is designed to be used in shell scripts that converts each way between Win32 and POSIX paths.
Here's a workaround for the problem. Start using bash and make the following modifications in config files.
Open ~/.bashrc
Add the following code at the end
wcd()
{
cd $(echo "$#" | sed 's/\\/\\\\/g')
}
Save it
Reload bash terminal.
Type
wcd ".\access"
along with the quotes and voila, you have your own windows compatible cd command.