Why stopping at generating a PGP key when building kernel? - centos

When I build CentOS6 kernel, it stops at the following steps:
###
### Now generating a PGP key pair to be used for signing modules.
###
### If this takes a long time, you might wish to run rngd in the background to
### keep the supply of entropy topped up. It needs to be run as root, and
### should use a hardware random number generator if one is available, eg:
###
### rngd -r /dev/hwrandom
###
### If one isn't available, the pseudo-random number generator can be used:
###
### rngd -r /dev/urandom
###
+ gpg --homedir . --batch --gen-key /home/build/rpmbuild/SOURCES/genkey
gpg: WARNING: unsafe permissions on homedir `.'
gpg: keyring `./secring.gpg' created
gpg: keyring `./pubring.gpg' created
Even wait for several hours, the build script won't go on. Have I must manually run rngd?
I built the kernel for several times, and only had once to successfully finished this step.

The output text tells you exactly what is going on: There isn't enough entropy to generate the GPG keys needed.
You can either run rngd as suggested, or you could try doing something like 'sudo find /'.

I have installed quite old package rng-utils-2.0-5.el5.x86_64.rpm on RHEL 6.4, hanged it on a /dev/urandm and managed to get gpg keys.

Related

vscode with ubuntu + wsl 2 never prompts for gpg passphrase even after configuration just "failed to write commit data"

I'm trying to get vscode to prompt for passphrase when trying to commit as it does in windows OR at least make the time between having to enter the passphrase a lot longer.
I'm using latest on ubuntu + WSL 2, both installed today.
GPG works in the CLI if I run a test as follows:
echo "test" | gpg --clearsign
I'm being prompted for a passphrase and all is well. Then I'd be able to sign commits in vscode temporarily.
Is there an option to make the time between entering the passphrase a lot longer at least as a workaround?
EDIT:
I also have to enter this everytime I reboot my computer:
export GPG_TTY=$(tty)
Otherwise the above workaround won't work. It's been insane trying to fix this, probably spent at least 1 full day but to no use.
In your ~/.gnupg/gpg-agent.conf file, add the following:
default-cache-ttl 28800
max-cache-ttl 28800
You can also add the following to your ~/.bashrc so you do not have to manually enter it each time:
export GPG_TTY=$TTY
echo "test" | gpg --clearsign > /dev/null 2>&1
This prompts me for my password once on start and should cache for 8 hours. The > /dev/null 2>&1 bit hides the output. Currently, this is the workaround I am using--which is not ideal but bearable.

Is there a way to install keys into the opkg-keyring during the yocto build process and have them marks as ultimate rather than unknown by gpg

My problem I think is very simple. I would like to have opkg verify signatures before installing packages from my custom opkg repository. The issue I am having is that the keys I added to the opkg-keyrings yocto recipe are all marked as unknown on the target by gpg. They are all installed though. So when i attempt to install a package form my custom repository, It fails because there are no trusted keys. I do not believe that this is a yocto bug, but I am running rocko.
Thank you.
I have gone through the relevant recipes and just don't see anything to change the behavior.
when i attempt to run opkg update i receive the following error.
Collected errors:
opkg_verify_gpg_signature: No sufficently trusted public keys found.
gpg -k result on target(verify fails)
uid [ unknown]
gpg -k result on pc where verify succeeds.
uid
[ultimate]
opkg-key populate
opkg-key adv --list-keys --fingerprint --with-colons |\
sed -E -n -e 's/^fpr:::::::::([0-9A-F]+):$/\1:6/p' |\
opkg-key adv --import-ownertrust
I wanted to add this for anyone who finds the question. I ended up adding a service at start up that runs a script that enables the keys. I have included the key portions of the script above.

Run a command in bitbake recipe as if on live system

Is it possible to run a command in a recipe as if it were run on the live system? If so, how? I want to import my key(s) into gpg before the image is created so I don't have to log onto the system after formatting the SD card.
I found a solution that involves specifying a post install script that runs when do_rootfs is called. All I added to my recipe which installs my public key on the system is below:
pkg_postinst_${PN}() {
#!/bin/sh
if [ -n "$D" ]; then
OPT="--homedir $D/home/root/.gnupg"
else
OPT=""
fi
gpg $OPT --import ${D}${datadir}/mykey.gpg
}

make check fails to start in Postgres 8.4.2

I am running into a strange error when trying to run PostgreSQL 8.4.2's regression suite on a new Ubuntu instance that I've created on Amazon EC2.
I can configure PostgreSQL successfully:
$ ./configure
[ Output not shown ]
$ tail -1 config.log
configure: exit 0
It builds just fine:
$ make
[ Ouput clipped ]
All of PostgreSQL successfully made. Ready to install.
But when I try to run the regression suite, I receive an error:
$ make check
[ Ouput clipped ]
make[2]: Entering directory `/home/ubuntu/stock/postgresql-8.4.2/src/test/regress'
You must use GNU make to use Postgres. It may be installed
on your system with the name 'gmake'.
However, I believe that I am running GNU Make:
$ make --version
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
This program built for x86_64-pc-linux-gnu
$ ls -l `which gmake`
lrwxrwxrwx 1 root root 13 Feb 6 17:41 /usr/bin/gmake -> /usr/bin/make
I see that in the src/test/regress directory, there is a Makefile:
$ cat src/test/regress/Makefile
# The Postgres make files exploit features of GNU make that other makes
# do not have. Because it is a common mistake for users to try to build
# Postgres with a different make, we have this make file that does nothing
# but tell the user to use GNU make.
# If the user were using GNU make now, this file would not get used because
# GNU make uses a make file named "GNUmakefile" in preference to "Makefile"
# if it exists. Postgres is shipped with a "GNUmakefile".
all install clean check installcheck:
#echo "You must use GNU make to use Postgres. It may be installed"
#echo "on your system with the name 'gmake'."
The comments in that Makefile indicate that there should be a file named GNUmakefile in that directory, but there is not:
$ ls src/test/regress/*akefile
src/test/regress/Makefile
There is a GNUMakefile in the top-level directory:
$ ls *akefile
GNUmakefile Makefile
Even when I force make and make check to use the GNUmakefile, via -f GNUmakefile, the same error occurs.
Note that I can run the regression suite just fine on my home machine.
Does any one have any ideas why it's not working on the EC2 instance?
EDIT: On my home machine, I'm running Ubuntu 12.04. The EC2 instance is running 13.10. Both machines are running make version 3.81.
You must have a messed up download or checkout. There should be a src/test/regress/GNUmakefile there, as you suspected. Try downloading again.
This is what that directory looks like on mine:
$ ls src/test/regress/*akefile
src/test/regress/GNUmakefile src/test/regress/Makefile

gpg with powershell

I used gnupg version 1.4 and this code in powershell to decrypt encrypted file worked fine:
echo mypassphrase | C:\gpg.exe --passphrase-fd 0 --output c:\list.xls --decrypt c:\gnupg\crypted\list.gpg
Now I've installed GNUPG2 and it doesn't work anymore. The only thing that changed is gpg.exe to gpg2.exe
When I run this command via command line it stucks here:
You need a passphrase to unlock the secret key for
user: "Marcel Seln (MS) <mseln#seln.sk>"
2048-bit RSA key, ID ED189121, created 2012-03-02 (main key ID 792EF596)
(only thing that helps is ctrl+c to interrupt command)
Thank you.
I found out that this problem occures too, when I use GNU Privacy Assistent. It freezes and CPU consumption was at 100%. I don't know why this happens on my brand new Windows server 2003 virtual machine, but when I restarted it, everything works fine. There is no suspicious event in Event log..
Thank you for your time!