Mailing List Archive: gpg via cgi under BSDi

gpg via cgi under BSDi

Jan 18, 2000, 3:26 AM

Post #1 of 4 (1090 views)

hi folks!

as you can imagine (cause of the subject) i have problems with gpg
(1.0.1) under BSDi v3.1.
research in the listings gave me the patch to get gpg compiled under
BSDi. it also works on the command line. but if i try to call it via a
cgi it stops working before it starts encoding.
if have no passphrase for the secret key but that should be ok, cause
the cgi-user won't decrypt anything sent to him.

i call gpg like that:
gpg --debug-all --encrypt --armor --no-tty --batch --homedir
/foobar/.gnupg --recipient someone@somewhere.com

input comes from stdin, output goes to stdout. it does not matter if i
specify a file for input and/or a file for output. on my linux box this
works just fine, i can even omit the --batch and --no-tty args.

i have two log snippets here, the first from the working commmand-line
call:

-------------------- snip
-------------------------------------------------------------
gpg: DBG: Ooops, m_size called
gpg: DBG: mpi_free_limb_space of size 0
gpg: DBG: iobuf-4.0: underflow: req=8192 got=0 rc=-1
gpg: DBG: /foobar/.gnupg/secring.gpg: close fd 3
gpg: DBG: iobuf-4.0: underflow: eof
gpg: DBG: iobuf-4.0: close `(null)'
gpg: DBG: check_trust() returns trustlevel 0005.
gpg: DBG: iobuf-6.0: open `[stdin]' fd=0
gpg: DBG: iobuf-7.0: create `file_filter'
gpg: DBG: armor-filter: control: 5
gpg: DBG: iobuf-7.1: push `armor_filter'
gpg: DBG: armor-filter: control: 5
gpg: DBG: iobuf chain: 7.1 `armor_filter' filter_eof=0 start=0 len=0
gpg: DBG: iobuf chain: 7.0 `file_filter' filter_eof=0 start=0 len=0
gpg: DBG: armor-filter: control: 1
gpg: DEK is: 82 07 A9 27 91 5A B1 97 EF E7 26 77 42 64 B9 02
gpg: DBG: mpi_alloc_secure(2048)
gpg: DBG: mpi_alloc_limb_space(2048)
gpg: DBG: pubkey_encrypt: algo=16
gpg:
pkey:D9505D44E90758442F8056BCE8364C85739424C1ACFD1AB9DFD1B5ABAF91FADCA756
-------------------- snap
-------------------------------------------------------------

and then it starts encoding...

now the log from the cgi-call:

-------------------- snip
-------------------------------------------------------------
gpg: DBG: Ooops, m_size called
gpg: DBG: mpi_free_limb_space of size 0
gpg: DBG: iobuf-4.0: underflow: req=8192 got=0 rc=-1
gpg: DBG: /foobar/.gnupg/secring.gpg: close fd 8
gpg: DBG: iobuf-4.0: underflow: eof
gpg: DBG: iobuf-4.0: close `(null)'
gpg: DBG: check_trust() returns trustlevel 0005.
gpg: DBG: iobuf-6.0: open `[stdin]' fd=0
gpg: DBG: iobuf-7.0: create `file_filter'
gpg: DBG: armor-filter: control: 5
gpg: DBG: iobuf-7.1: push `armor_filter'
gpg: DBG: armor-filter: control: 5
gpg: DBG: iobuf chain: 7.1 `armor_filter' filter_eof=0 start=0 len=0
gpg: DBG: iobuf chain: 7.0 `file_filter' filter_eof=0 start=0 len=0
gpg: DBG: armor-filter: control: 1
-------------------- snap
-------------------------------------------------------------

as you can see, it stops before this DEK (whatever that is, looks
somehow like a fingerprint) thing is done. well, stopping is not the
right term. it just hangs and does nothing more, no quitting, no
advancing :(

i would appreciate some help here.

keep up the excellent work, tia,
sebastian
--
defcom webdressing gmbh
ohlauer str. 42
10999 berlin
phone: +49 30 617 76 999

Re: gpg via cgi under BSDi [ In reply to ]

wk at gnupg

Jan 18, 2000, 5:28 AM

Post #2 of 4 (1082 views)

Permalink

On Tue, 18 Jan 2000, Sebastian Henschel wrote:

> as you can see, it stops before this DEK (whatever that is, looks

data encryption key = the random session key which is used for
symmentric encryption of the data.

> somehow like a fingerprint) thing is done. well, stopping is not the
> right term. it just hangs and does nothing more, no quitting, no
> advancing :(

I guess it is collecting random - did you use EGD?
Or something is wrong with your CGI program, run it under strace/truss
to see where it hangs.

--
Werner Koch at guug.de www.gnupg.org keyid 621CC013

Boycott Amazon! - http://www.gnu.org/philosophy/amazon.html

Re: gpg via cgi under BSDi [ In reply to ]

shensche at defcom

Jan 19, 2000, 6:02 AM

Post #3 of 4 (1098 views)

Permalink

hello again..

Werner Koch wrote:
>
> > as you can see, it stops before this DEK (whatever that is, looks
>
> data encryption key = the random session key which is used for
> symmentric encryption of the data.
>
> > somehow like a fingerprint) thing is done. well, stopping is not the
> > right term. it just hangs and does nothing more, no quitting, no
> > advancing :(
>
> I guess it is collecting random - did you use EGD?
no, i did not. but how can i do that under BSDi?
i started the demon as proposed (egd.pl ~/.gnupg/entropy) and put
"load-extension rndegd" into my options file.
but gpg seems to use the file /usr/local/lib/gnupg/rndegd and outputs
the following:

gpg: /usr/local/lib/gnupg/rndegd: error loading extension: can't process
object file: Inappropriate file type or format

when i start egd with "egd.pl /usr/local/lib/gnupg/rndegd" gpg says:

gpg: /usr/local/lib/gnupg/rndegd: error loading extension: can't process
object file: Operation not supported

"cat"ting this file now gives me nearly the same answer. btw it seems to
have always the size of 0, rights: 4777.

a snippet with --debug-all (although i have no idea where to start
concerning this egd matter):

------------------ snip -------------------------
# similar stuff before
gpg: DBG: mpi_alloc(2048)
gpg: DBG: mpi_alloc_limb_space(2048)
gpg: DBG: mpi_alloc(32)
gpg: DBG: mpi_alloc_limb_space(32)
gpg: DBG: mpi_alloc(2048)
gpg: DBG: mpi_alloc_limb_space(2048)
gpg: DBG: parse_packet(iob=3): type=2 length=75 (parse.ringedit.c.1237)
gpg: DBG: mpi_alloc(160)
gpg: DBG: mpi_alloc_limb_space(160)
gpg: DBG: mpi_alloc(160)
gpg: DBG: mpi_alloc_limb_space(160)
gpg: DBG: iobuf-3.0: underflow: req=8192 got=0 rc=-1
gpg: DBG: /foobar/.gnupg/pubring.gpg: close fd 3
gpg: DBG: iobuf-3.0: underflow: eof
gpg: /usr/local/lib/gnupg/rndegd: error loading extension: can't process
object file: Operation not supported
gpg: DBG: mpi_alloc(2048)
gpg: DBG: mpi_alloc_limb_space(2048)
gpg: DBG: mpi_alloc(32)
gpg: DBG: mpi_alloc_limb_space(32)
gpg: DBG: mpi_alloc(2048)
gpg: DBG: mpi_alloc_limb_space(2048)
gpg: DBG: free_packet() type=6
gpg: DBG: mpi_free
gpg: DBG: Ooops, m_size called
gpg: DBG: mpi_free_limb_space of size 0
gpg: DBG: mpi_free
# similar stuff afterwards
------------------ snap -------------------------
*sigh*

i remind you all, that you cannot make gnupg with
"--enable-static-rnd=none" or "--enable-static-rnd=egd" on BSDi. and you
have to touch the startup rndegd, tiger, rndunix in the cipher dir of
the source tree (which are found afterwards in /usr/local/lib/gnupg).

> Or something is wrong with your CGI program, run it under strace/truss
> to see where it hangs.
unfortunately strace does not support BSDi (i start hating this
derivate).
well, ktrace (as replacement for truss) does not give _me_ so much more
info. one thing i found interesting is that another gpg-process is
forked shortly before the programm hangs. although in the ktrace dump
you can only see the fork, but in the process list you have two gpgs
running. if anyone is interested i can post him/her the whole output
(about 30K) until i killed the process.

slightly desperate, tia
sebastian
--
defcom webdressing gmbh
ohlauer str. 42
10999 berlin
phone: +49 30 617 76 999

Re: gpg via cgi under BSDi [ In reply to ]

wk at gnupg

Jan 19, 2000, 6:43 AM

Post #4 of 4 (1081 views)

Permalink

On Wed, 19 Jan 2000, Sebastian Henschel wrote:

> gpg: /usr/local/lib/gnupg/rndegd: error loading extension: can't process
> object file: Inappropriate file type or format

So the dynamic linking does not work

> i remind you all, that you cannot make gnupg with
> "--enable-static-rnd=none" or "--enable-static-rnd=egd" on BSDi. and you

Why? --enable-static-rnd=egd does not need any dynamically linked
modules and is pretty standard C.

> well, ktrace (as replacement for truss) does not give _me_ so much more
> info. one thing i found interesting is that another gpg-process is
> forked shortly before the programm hangs. although in the ktrace dump

The only fork is done in cipher/rndunix.c - so you are using this one
and therefore it may a) take quite long or b) does not work at all due
to some strange behaviour of your system.

--
Werner Koch at guug.de www.gnupg.org keyid 621CC013

Boycott Amazon! - http://www.gnu.org/philosophy/amazon.html