Starting: Thu Sep 21 2000 - 06:55:29 EST
Ending: Mon Oct 23 2000 - 03:35:48 EST
The command-line versions are great and all, but getting the
functionality up to "Drop in replacement" for the windows/mac
versions (with their nice integration into Eudora/Outlook/etc.) would
definitely be a step in the right direction.
D
I looked at doing a port last year. However, gnupg seems to have been
written solely with a command line interface in mind, just like PGP.
At
first glance, major surgery seemed to be required to turn it into an
event
driven GUI app. I recoiled in fear, and worked on other things.
I've heard rumblings about a lib version that may ease a port to Mac
OS
(and Windows), but haven't had time to keep up with the list lately.
Richard
> I looked at doing a port last year. However, gnupg seems to have
been
> written solely with a command line interface in mind, just like
PGP. At
> first glance, major surgery seemed to be required to turn it into
an event
> driven GUI app. I recoiled in fear, and worked on other things.
Thinkbout components. There will be something to use GnuPG
formother apps. No scheduleyet.
Werner
-- Werner Koch GnuPG key: 621CC013 OpenIT GmbH http://www.OpenIT.de
> Thinkbout components. There will be something to use GnuPG
> formother apps. No scheduleyet.
I have been thinking about something like this
for a little while. Is
anyone coding this sort of thing at the moment?
I don't mean a GUI (I am
aware of those), but a library to expose the
functionality of GPG?
I would love to be able to ask my code to sign
a document and then
verify the signature nightly, that sort of thing.
This is better off in
C code because of some of the other issues the
code has to deal with,
and I dislike 'system'ing ang 'exec'ing too often.
I have looked at g10.c, but couldn't see an easy
way to turn that entry
point into a series of function calls with the
command lines options
turned into arguments... Does anyone have some
ideas about how to handle
this sort of thing?
If no-one minds I'll have a play with coding something
up in the next
few days...
Mikal
--Michael Still (mikal) http://www.stillhq.com mailto:mikal@stillhq.com
> I have been thinking about something like this for a little while.
Is
> anyone coding this sort of thing at the moment? I don't mean a
GUI (I am
> aware of those), but a library to expose the functionality of
GPG?
The --status-fd option works reasonably well for me. I found a couple
of nuisances though:
Firstly if a key has more than one uid, only the first one is reported
on the status stream. This makes all the subsequent ones unusable if
you are using this interface to gnupg.
Secondly if you want to verify a detached signature, you have to write
either the signature or the data to a file. It would be nice if you
could provide the signature on one file descriptor and the data on
another, for example.
Fundamentally, these are fairly large issues.
The largest issue I see here is the need to create files to interface with
gpg at the moment. This has various problems, including:
I agree that a library would be nice, but it isn't essential for
me.
-- Pete
Pete Chown, at 12:55 +0100 on Mon, 25 Sep 2000, wrote:
> Secondly if you want to verify a detached signature, you have to
write
> either the signature or the data to a file. It would be nice if
you
> could provide the signature on one file descriptor and the data
on
> another, for example.
I agree; I have found this to be a problem also, and wish it could be
solved via a manner you described.
The ongoing theme in this document seems to be that the gnupg team is ignoring a fairly large market segment... This form of requent is fairly common, as seen from the messages so far.
- --
Frank Tobin http://www.uiuc.edu/~ftobin/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.3 (FreeBSD)
Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/
iEYEARECAAYFAjnPR7sACgkQVv/RCiYMT6MD9gCgn+FYXgKQtOi/FD690ThVcKoN
+wsAniO6aPvDdMAXEjthVud7XJV6he1+
=hkkf
-----END PGP SIGNATURE-----
> Firstly if a key has more than one uid, only the first one is reported
> on the status stream. This makes all the subsequent ones unusable
if
> you are using this interface to gnupg.
To you mean GOODSIG? A workaround is to use the given keyid to
lookup all the other UIDs. I don't think it is a good idea to emit
more than one GOODSIG for one signature. So a new keyword would do
the job.
Werner has occassionally offered work arounds for the lack of an API with which to access GPG, but fundamentally an API is still the most appropriate solution to the problem.
BTW, in 1.1 we will have the notation of a primary user ID which
should get used for displayed user IDs; it is calculated by looking
at the primary user ID flag and the creation times of the user IDs.
> Secondly if you want to verify a detached signature, you have to
write
> either the signature or the data to a file. It would be nice if
you
> could provide the signature on one file descriptor and the data
on
> another, for example.
Makes sense. Probably we have to add this anyway to support the
GPAPA library.
GPAPA is, to my understanding, a wrapper library which does all the handling of the creation of temporary files and the calling of GPG on the command line for you. This does not address issues such as the relative insecurity of this process, as well as it inefficiency.
Ciao,
Werner
-- Werner Koch GnuPG key: 621CC013 OpenIT GmbH http://www.OpenIT.de
Has anybody considered putting the core functionality of gpg into a
library,
and then writing a comparatively small wrapper around for the command
line
interface?
This would allow individual interfaces and uses of gpg to spring up
MUCH more
easily, as it would then be much easier to find the code you want,
the options
you want, etc.
I've considered undertaking such a task, but don't know how well received
it
would be.
-- Michael J. Pedersen My GnuPG KeyID: 4E724A60 My Public Key Available At: wwwkeys.pgp.net My GnuPG Key Fingerprint: C31C 7E90 5992 9E5E 9A02 233D D8DD 985E 4E72 4A60 GnuPG available at http://www.gnupg.org
It would make things a lot easier to develop. Since I develop
using
Delphi as well as C/c++ it would be nice to be able to make use of
GPG
directly from delphi via a DLL, as with PGP_SDK. This would save
creating temporary files etc.
I havn't tried it but i presume you could already do this with
C since
the source fore GNUPG is in C?
I think its something that would be very useful in the future.
Bye,
Gary Preston
Gary@e-c-s-uk.com
> be compiled as either gpg as currently does. However also options
to
> compile as windows.dll unix library format etc.
No.
* Big monolithic programs are not a very intelligent design and
in
most cases very error prone (See Netscape, Linux
etc. )
* Shared libraries might be better but in the end it is still
one
program with not so well defined interfaces. Building
programs
based on shared libraries is causing a lot of headache
- ever
tried to build Mozilla or Evolution?
* Unix was successul because of KISS (Keep it simple and small).
All the small, quite well tested modules/programs/components
do
work (more or less) nicely together and we can develop
and
maintain small modules and modules which utilize
other modules.
It is far from perfect but a rock solid foundation
for many
tasks.
* Components are probably somewhat better and a thing we can
do
nowdays. With the right framework they can take
the part all
the small Unix tools have now.
That's my take on that. While we are heading for components we must
do something in the meantime; and that are wrapper libraries like PGG
or GPAPA.
That's my take on this.
Werner
-- Werner Koch GnuPG key: 621CC013 OpenIT GmbH http://www.OpenIT.de
[snip]
I find that a very short-sighted view. gnupg is _not_ small and will
never expose sufficient interfaces in a command-line form. I'd like
to
be able to use gnupg to do far more complex things than it already
does.
Are you going to provide _everything_ on the command line?
This statement is entirely correct. It feels based on Werner's response that he is starting to feel like this whole thing is a personal attack on him (which it isn't, people are just trying to improve the functionality of GPG). GPG is not a small package, as shown by the following script output:
[mikal@deathstar cipher]$ wc -l *.[ch]
41 bithelp.h
595 blowfish.c
44 blowfish.h
622 cast5.c
33 cast5.h
653 cipher.c
20 construct.c
1010 des.c
34 des.h
477 dsa.c
32 dsa.h
586 dynload.c
68 dynload.h
666 elgamal.c
35 elgamal.h
46 g10c.c
523 md.c
410 md5.c
575 primegen.c
618 pubkey.c
30 rand-internal.h
676 random.c
41 random.h
35 rmd.h
632 rmd160.c
255 rndegd.c
242 rndlinux.c
914 rndunix.c
963 rndw32.c
463 rsa.c
36 rsa.h
408 sha1.c
114 smallprime.c
991 tiger.c
1065 twofish.c
13953 total
[mikal@deathstar g10]# wc -l *.[ch]
1080 armor.c
1032 build-packet.c
152 cipher.c
103 comment.c
285 compress.c
122 dearmor.c
82 decrypt.c
163 delkey.c
502 encode.c
252 encr-data.c
235 export.c
133 filter.h
453 free-packet.c
1720 g10.c
2022 getkey.c
275 helptext.c
230 hkp.c
30 hkp.h
1339 import.c
382 kbnode.c
222 keydb.h
1976 keyedit.c
1810 keygen.c
431 keyid.c
481 keylist.c
162 main.h
1273 mainproc.c
76 mdfilter.c
255 misc.c
323 openfile.c
121 options.h
363 packet.h
1763 parse-packet.c
297 passphrase.c
1157 pkclist.c
400 plaintext.c
223 pubkey-enc.c
354 revoke.c
1856 ringedit.c
306 seckey-cert.c
211 seskey.c
553 sig-check.c
883 sign.c
179 signal.c
156 skclist.c
519 status.c
104 status.h
525 tdbdump.c
1752 tdbio.c
198 tdbio.h
235 textfilter.c
2749 trustdb.c
82 trustdb.h
164 verify.c
32751 total
[mikal@deathstar include]$ wc -l *.[ch]
181 cipher.h
80 errors.h
43 host2net.h
80 http.h
50 i18n.h
149 iobuf.h
84 memory.h
178 mpi.h
35 ttyio.h
124 types.h
229 util.h
1233 total
[mikal@deathstar intl]$ wc -l *.[ch]
203 bindtextdom.c
262 cat-compat.c
655 dcgettext.c
59 dgettext.c
198 explodename.c
216 finddomain.c
70 gettext.c
105 gettext.h
89 gettextP.h
59 hash-string.h
76 intl-compat.c
411 l10nflist.c
182 libgettext.h
78 loadinfo.h
220 loadmsgcat.c
438 localealias.c
108 textdomain.c
3429 total
[mikal@deathstar mpi]$ wc -l *.[ch]
95 g10m.c
1497 longlong.h
247 mpi-add.c
262 mpi-bit.c
74 mpi-cmp.c
322 mpi-div.c
54 mpi-gcd.c
36 mpi-inline.c
129 mpi-inline.h
259 mpi-internal.h
270 mpi-inv.c
101 mpi-mpow.c
198 mpi-mul.c
295 mpi-pow.c
132 mpi-scan.c
446 mpicoder.c
62 mpih-cmp.c
537 mpih-div.c
527 mpih-mul.c
462 mpiutil.c
6005 total
[mikal@deathstar util]$ wc -l *.[ch]
988 argparse.c
375 dotlock.c
109 errors.c
158 fileutil.c
40 g10u.c
777 http.c
1578 iobuf.c
270 logger.c
593 memory.c
336 miscutil.c
431 secmem.c
485 simple-gettext.c
589 strgutil.c
452 ttyio.c
88 w32reg.c
7269 total
In my book 64,640 lines of code cannot be described as simple and small. Werner also ignores that while there is a justification for modular code from the view of supportability, it is not the fundamental reason for the instability of products such as Netscape and Microsoft Windows. I am not sure what he is getting at with his comment about Linux.
In addition, Werner also ignores the fact that the GPG user interface could be made much more robust by reducing it to a few thousand lines of code that simply calls a library interface. Each of the methods in the library could also be implemented as a relatively separate module, which make the code much more robust than it currently is.
The reason that Mozilla and Evolution are hard to build is because they
tried to put too much functionality into one program. I just want to
provide _small_ programs which provide variant functionality similar
to
gpg.
Also, Werner is trying to implement all functionality under the sun in the GPG user interface, which falls apart under his own arguement.
For example, I'd like to make a small program which enables me to edit
PGP files in a more advanced manner -- adding/removing subpackets,
subkeys, etc. I doubt you really want to dedicate your time to this
(and
all the other) project(s) which people might want.
As for interfaces, that can be worked on. Here's an overview of the
process:
* List all functionality in the system
* Partition the system into modules
* Define the exposed part of each module
* Define the inter-module dependencies
* Create the API for the modules
And voila! If you do it right, you end up with a very usable system
which is not complex, not bloated, and not monolithic. Would anyone
be
interested in helping me do this?
-- Taral <taral@taral.net> Please use PGP/GPG to send me mail. "Never ascribe to malice what can as easily be put down to stupidity."
> I find that a very short-sighted view. gnupg is _not_ small and will
Right it is already too large and I am going to address this in gpg
1.1.
> The reason that Mozilla and Evolution are hard to build is because
they
> tried to put too much functionality into one program. I just want
to
> provide _small_ programs which provide variant functionality similar
to
I can't agree. At least from my experience with Evolution, the
problem is that there are so many libaraiers and interfaces and
everything depends on each other - which is good of course. As
long as those interfaces are not yet frozen and stable it is
complicated to build the thing. Frankly, it is not complicated, but
you need to do many, many cvs updates, and build in the right order.
Werner is correct is saying that library APIs shouldn't change. This doesn't stop the internal code from changing though, so long as those external interfaces and the side-effects of the code remain the same.
> For example, I'd like to make a small program which enables me
to edit
> PGP files in a more advanced manner -- adding/removing subpackets,
There is always the source code. gpg 1.1 will make the interfaces
more modular.
Including the GPG source code in another project is a very bad idea. It means that when a security hole is found it will probably not be plugged because the interdependance of the two code bases needs to be actively maintained. A library providing an API is better because it leaves systems administrators with only one place where they have to update the code for GPG when a security hole is found. It is also a more efficient use of the systems available disk storage space.
> * List all functionality in the system
> * Partition the system into modules
> * Define the exposed part of each module
> * Define the inter-module dependencies
> * Create the API for the modules
That is a lot of work and I prefer to invest the time in auditing and
making the code cleaner.
Eventually, the packet handling code etc, will be separated and that
means that it can be put into a library you can grab.
Werner
-- Werner Koch GnuPG key: 621CC013 OpenIT GmbH http://www.OpenIT.de
Werner Koch, at 17:23 +0200 on Thu, 19 Oct 2000, wrote:
> I can't agree. At least from my experience with Evolution, the
> problem is that there are so many libaraiers and interfaces and
> everything depends on each other - which is good of course. As
> long as those interfaces are not yet frozen and stable it is
> complicated to build the thing. Frankly, it is not complicated,
but
> you need to do many, many cvs updates, and build in the right
order.
Interfaces are always frozen if you design well at the beginning.
> > * List all functionality in the system
> > * Partition the system into modules
> > * Define the exposed part of each module
> > * Define the inter-module dependencies
> > * Create the API for the modules
>
> That is a lot of work and I prefer to invest the time in auditing
and
> making the code cleaner.
This is exactly the approach that software engineering courses and books
teach against (unless you are doing XP, of course, which GnuPG doesn't
seem to be doing).
- --
Frank Tobin http://www.uiuc.edu/~ftobin/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/
iEYEARECAAYFAjnvSM0ACgkQVv/RCiYMT6MTQACdH4LTLo0fapimV+JrYbd4JGtx
XqEAnRtuqAg4MN5FCEq5g67Mr2kM+Pfz
=TgDu
-----END PGP SIGNATURE-----
Muawahha!!!
Thanks, this had been a rough day. Thanks for the laugh.
The quality of this person's comment makes their pre-conceived ideas evident. It is trivial to maintain an interface for an API, new functionality is merely implemented as a new method within the API.
> > > * List all functionality in the system
> > > * Partition the system into modules
> > > * Define the exposed part of each module
> > > * Define the inter-module dependencies
> > > * Create the API for the modules
> >
> > That is a lot of work and I prefer to invest the time in auditing
and
> > making the code cleaner.
>
> This is exactly the approach that software engineering courses
and books
> teach against (unless you are doing XP, of course, which GnuPG
doesn't
> seem to be doing).
And yet you are saying this is a bad thing?
I don't understand.
I fully support the goal of auditing the code and making it cleaner
over
making a library, even though my job would be made _so_ much easier
if
there was a gnupg library (see http://www.immunix.org/cryptomark.html
for more info.)
greg k-h
-- greg@(kroah|wirex).com http://immunix.org/~greg
Greg KH, at 13:46 -0700 on Thu, 19 Oct 2000, wrote:
> > This is exactly the approach that software engineering courses
and books
> > teach against (unless you are doing XP, of course, which GnuPG
doesn't
> > seem to be doing).
>
> And yet you are saying this is a bad thing?
> I don't understand.
I'm saying that, for larger projects, software engineering teaches that
design is supposed to encompass the large majority of the development
(unless doing XP, of course, again, which GnuPG is not, or else there
wouldn't be a heavy need for auditing).
The original message by Taral stated a desire for creating something
to
process/system diagrams for how GnuPG works, and implementing in in
a
clean, modularized way. Werner stated:
That is a lot of work and I prefer to invest the time in auditing
and
making the code cleaner.
This seems like refactoring the code a lot, but it doesn't scale well,
or
generally take into account the needs for third-parties to interact
with
the system.
> I fully support the goal of auditing the code and making it cleaner
> over making a library, even though my job would be made _so_ much
> easier if there was a gnupg library (see
> http://www.immunix.org/cryptomark.html
for more info.)
The desire being scrutinzed isn't just to make it a library, but to
develop GnuPG into a modularized system, well with-defined interfaces,
and
connetions between those interfaces.
- --
Frank Tobin http://www.uiuc.edu/~ftobin/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/
iEYEARECAAYFAjnvhjsACgkQVv/RCiYMT6OamwCgmpBREwP8W1ourGTOz0rGeIWy
IZcAn2/1KS4i5476CwdwUkbKpEl6zZyl
=5QSW
-----END PGP SIGNATURE-----
> On Thu, Oct 19, 2000 at 02:17:32PM -0500, Frank Tobin wrote:
> > Interfaces are always frozen if you design well at the beginning.
>
> Muawahha!!!
> Thanks, this had been a rough day. Thanks for the laugh.
*grin* I couldn't bring myself to comment on it.
> > This is exactly the approach that software engineering courses
and
> books
> > teach against (unless you are doing XP, of course, which GnuPG
> doesn't
> > seem to be doing).
>
> And yet you are saying this is a bad thing?
> I don't understand.
Nor do I. Why would a book teach against that?
> I fully support the goal of auditing the code and making it cleaner
> over
> making a library, even though my job would be made _so_ much easier
if
> there was a gnupg library (see http://www.immunix.org/cryptomark.html
> for more info.)
Well, hopefully the audit will result in sufficient modularity/stability
that
someone else can fully library-ize the code.
-- Taral <taral@taral.net> -------------------------------------------------------------------------- This mail sent through the UT Austin Webmail service, https://webmail.utexas.edu
http://www.fourmilab.ch/autofile/www/chapter2_108.html
Enzo
----- Original Message -----
From: "Frank Tobin" <ftobin@uiuc.edu>
To: <gnupg-devel@gnupg.org>
Sent: Friday, October 20, 2000 3:17 AM
Subject: Re: No GnuPG library for now
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Werner Koch, at 17:23 +0200 on Thu, 19 Oct 2000, wrote:
>
> > I can't agree. At least from my experience with Evolution, the
> > problem is that there are so many libaraiers and interfaces
and
> > everything depends on each other - which is good of course.
As
> > long as those interfaces are not yet frozen and stable it is
> > complicated to build the thing. Frankly, it is not complicated,
but
> > you need to do many, many cvs updates, and build in the right
order.
>
> Interfaces are always frozen if you design well at the beginning.
>
> > > * List all functionality in the system
> > > * Partition the system into modules
> > > * Define the exposed part of each module
> > > * Define the inter-module dependencies
> > > * Create the API for the modules
> >
> > That is a lot of work and I prefer to invest the time in auditing
and
> > making the code cleaner.
>
> This is exactly the approach that software engineering courses
and books
> teach against (unless you are doing XP, of course, which GnuPG
doesn't
> seem to be doing).
>
> - --
> Frank Tobin http://www.uiuc.edu/~ftobin/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.4 (FreeBSD)
> Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/
>
> iEYEARECAAYFAjnvSM0ACgkQVv/RCiYMT6MTQACdH4LTLo0fapimV+JrYbd4JGtx
> XqEAnRtuqAg4MN5FCEq5g67Mr2kM+Pfz
> =TgDu
> -----END PGP SIGNATURE-----
Enzo Michelangeli, at 07:40 +0800 on Fri, 20 Oct 2000, wrote:
> For a reply from the real world, see:
>
> http://www.fourmilab.ch/autofile/www/chapter2_108.html
This is starting to get off-track, but there are two major trains of
thought on the whole issue; we have the 'design' process (a.k.a. Rational
Unified Process, a.k.a. RUP) vs a 'evolutionary' process (a.k.a. Extreme
Programa, a.k.a. XP). There are heavy debates on both sides of the
issue
which is better in the long run, which is better for which things,
etc.
Neither should be taken as the gospel truth.
Some of us on the list are simply expressing that GnuPG might benefit
from
having a little more of one process than another, given certain demands
from the public.
- --
Frank Tobin http://www.uiuc.edu/~ftobin/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/
iEUEARECAAYFAjnvijYACgkQVv/RCiYMT6NDpQCdH7ZMT263WMnmQRnWKcJXHuij
WT4Al2yjG12rV3M+j/ATG3kSjFPujJ0=
=AY/f
-----END PGP SIGNATURE-----
Actually, since this is an OpenSource project, demands from the public
usually work best when accompanied by a patch :)
This poster previously made a request for a GPG API, so this comment should be taken with a grain of salt.
greg k-h
-- greg@(kroah|wirex).com http://immunix.org/~greg
> > > * List all functionality in the system
> > > * Partition the system into modules
> > > * Define the exposed part of each module
> > > * Define the inter-module dependencies
> > > * Create the API for the modules
> >
> > That is a lot of work and I prefer to invest the time in auditing
and
> > making the code cleaner.
>
> This is exactly the approach that software engineering courses
and
> books
> teach against (unless you are doing XP, of course, which GnuPG
doesn't
> seem to be doing).
Well, I _am_ an XP advocate to a certain extent. It always made sense
to me.
What I listed is basically what every large software project I work
on
eventually has had to do to avoid becoming spaghetti (or worse).
-- Taral <taral@taral.net> -------------------------------------------------------------------------- This mail sent through the UT Austin Webmail service, https://webmail.utexas.edu
> This is starting to get off-track, but there are two major trains
of
> thought on the whole issue; we have the 'design' process (a.k.a.
Rational
> Unified Process, a.k.a. RUP) vs a 'evolutionary' process (a.k.a.
Extreme
> Programa, a.k.a. XP). There are heavy debates on both sides of
the issue
> which is better in the long run, which is better for which things,
etc.
Some software is developed from "Requirements" document. This is the
foundation of RUP. From there you construct your methods, data flow,
algorithms, code and tests. After the software passes its own tests
it is done. No further development is possible with this software,
only
occasional maintenance (bug fixes) because the design does not allow
"unnecessary" extensions and additions that were not planned beforehand.
For example, you can not easily add a plow or lawnmower to your car
(unless you watch "Red Green Show", of course :) This is because the
car was designed as final, complete product. At most you can add a
cup holder or better radio. This is RUP design.
Another example would involve a farm vehicle. It was -designed- to
work with various accessories, existing and future, as long as they
conform to some predefined and cast in stone interface. This is less
rigid design, but nevertheless it is not an evolutionary approach.
To see a vehicle that uses evolutionary design we can go to F-1 or
Indy race track. Very little is fixed there (and what is fixed is
so mostly because of rules of the sport). Every year you see changes
here and there - different wings, better engines, smarter computers.
This I would call an evolutionary design. It starts not with a good
description of the final product but with a good understanding of
what that product must do. The weight shifts from implementation to
fitness to the purpose.
With regard to GnuPG, is it fair to say that the program must do this
and that and nothing else? Do we -have- a formal specification of what
the final product will be? Most importantly, do we -need- such
specification? Parts of the code that interface with other components
(like 3rd party shells) would benefit from such standard. However the
rest of the code, I think, could be better treated as a "black box".
As long as I can invoke gpg in some predefined ways I, as user, don't
care if gpg uses callbacks to get to ciphers or it has a huge switch()
statement hardcoded somewhere.
That's why I was unhappy about yet another option being proposed for
GnuPG. The command interface must be designed as RUP because it
is an external interface and too many other programs depend on it.
However the internal structure of modules should be hidden from
any other code that does not need to know. Interface/Implementation
concept is pretty old - I believe Modula 2 had it long ago.
Anyway, the point is that RUP is a well known reason of -failure- of
large software projects when applied incorrectly. Try to order a
custom suit without trying it on couple of times before it is done.
If a tailor can't make just a suit then how much harder would it be
to foresee all possible changes that implementation may require!
RUP design is much more rigid than a XP one; the result is weird
extra variables passed back and forth, kludgy callbacks where there
shouldn't be any, etc. etc. - only because the "right" change would
involve several components, not just one. Often the project goes on
for so long that the design specification changes while you work!
This is very typical for accounting/materials/business applications.
GnuPG is also like that - new algorithms are added, new interfaces,
some code gets redesigned... it is not exactly a one-time job to be
done on December 17th and that's it. There are so many possible
extensions and improvements (like interface to a biometric scanner,
to name just one) that people will be hacking the code for long,
long time.
Said that, RUP remains a very solid method of development when large
teams are involved. You can not just email 200 developers asking them
to change all their code because you alone decided that this will be
"good". Investment in RUP process is dwarfed by stable, predictable,
manageable design process. XP, on the other hand, seems to be better
for small to medium sized projects that are "brainstormed" by few good
programmers. Losses on redesign are relatively low there and the
quality of the final product may be better. But, as usual, it all depends
on uncountable number of other factors... you can't just compare a
hardwired robot and a bird. On average they have probably the same
IQ,
but how helpful that is? Robot is better on assembly line; the crow
will
learn all your tricks and find a hidden food.
Cheers,
Dmitri
__________________________________________________
Do You Yahoo!?
Yahoo! Messenger - Talk while you surf! It's FREE.
http://im.yahoo.com/
Werner Koch, at 14:14 +0200 on Thu, 19 Oct 2000, wrote:
> * Shared libraries might be better but in the end it is still one
> program with not so well defined interfaces. Building programs
> based on shared libraries is causing a lot of headache - ever
> tried to build Mozilla or Evolution?
Don't forget the functionality of Mozilla is available seperately, via
Gecko, and implemented in other programs such as Galeon.
- --
Frank Tobin http://www.uiuc.edu/~ftobin/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/
iEYEARECAAYFAjnvRwcACgkQVv/RCiYMT6Mr0ACgogAOOANkAeFNOvLXf0pOAwsJ
rXUAoKmCt3QGALIEGp1Xz6VSjbEZfTuW
=CY6z
-----END PGP SIGNATURE-----
> * Shared libraries might be better but in the end it is still one
> program with not so well defined interfaces. Building programs
> based on shared libraries is causing a lot of headache - ever
> tried to build Mozilla or Evolution?
> * Unix was successul because of KISS (Keep it simple and small).
> All the small, quite well tested modules/programs/components do
> work (more or less) nicely together and we can develop and
> maintain small modules and modules which utilize other modules.
> It is far from perfect but a rock solid foundation for many
> tasks.
I'm not sure I'm completely following what you're saying, but there
are
some real problems with the separate program approach in practice.
A fork
consumes a lot of resources and can be difficult to manage well.
This confirms the statement I made previously in this document that executing someone else program with a command line invokation from within your program is inefficient. A fork() is the name of the system call to perform this process. It is normally followed by an exec(). An easier to use, but less efficient option would be to use the system() call.
My experience in this area is with writing news servers, which currently
often use PGP to authenticate newsgroup control messages (create, remove,
etc.) by checking their signatures. We've found from hard experience
that
forking off a control message handler for each incoming control message
makes the system extremely vulnerable to denial of service attacks.
INN, to take a concrete example, is a long-running server that tends
to
allocate 50MB or more of memory for various memory caches, temporary
article storage, and the like, and in addition memory maps often upwards
of 500MB of databases. Forking an external handler on some systems
means
reserving hundreds of MB of swap (which thankfully due to copy on write
aren't actually used, but the reservation process itself can be
expensive) and closing hundreds of open file descriptors that are marked
close on exec (and also invalidating all those memory maps, although
one
would hope that was reasonably efficient). One also has to then manage
the forked process, reap it properly, and limit how frequently one
is
willing to fork processes in order to keep from forking the system
to
death.
For newsgroup control messages, you can deal with this by having INN
fork,
when it starts, a separate handler process that just deals with newsgroup
control messages and forks the verification program and so forth. This
handler process is nice and small and can churn through requests handling
them one at a time. But that only works for things like newsgroup control
messages which INN accepts, hands off, and forgets about.
We'd like to expand the authentication features of Usenet to cover
moderated newsgroups as well, but trying to do this by forking an external
process for every post to a moderated newsgroup is going to basically
be a
non-starter and this can't be handled using the method described above.
INN has to get back an accept or reject decision from the validator;
it
can't just dispatch the message off to some handler and then forget
about
it. It's possible that GnuPG is the wrong tool to even look at for
doing
this and we should be using OpenSSL and a certificate system instead,
but
I'd hate to disqualify GnuPG for non-crypto-based reasons. Some way
of
verifying signatures via a library interface that does not involve
a fork
would be *very* nice.
-- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
> I'm not sure I'm completely following what you're saying, but there
are
> some real problems with the separate program approach in practice.
A fork
> consumes a lot of resources and can be difficult to manage well.
Depends on what you do. The most resource intensive operations (in
terms of processing time) are definetly the crypto operations. There
is not much you can gain in performance if you remove the fork. OTH
I see see the problems of a system which has to verify a lot of
signatures - If I had to to do this now, I'd write a daemon which
cares about signature verification. And i it turns out that you are
runnin out of memory or kernel table space, there is the possibility
to add a fast verify interface to GnuPG which make gpg hanging in a
loop wait for signatures to verify. It is not complicated to do it:
code it (g10/g10.c) and may be you have to address a few memory allocation
issues.
We have an application at work where we would like to be using GPG to verify the signatures on nine million files nightly. This is an example of where a signature verification daemon would be Werner's proposed solution. This however would require us to extract the verification code from the main GPG code base, with the problems that this involves -- as previously discussed.
I believe that the implementation of the API option would make this easier for the average coder, and therefore more likely to occur. It also doesn't require much more effort from Werner, as he largely has to develop this code for the command line interface anyway.
Werner
BTW, we are doing consulting and if you ask us, we can implement it
for you ;)
-- Werner Koch GnuPG key: 621CC013 OpenIT GmbH http://www.OpenIT.de
>Some way of verifying signatures via a library interface that does
not involve
>a fork would be *very* nice.
All you'd need to do is implement it as a COM in-process component under
Windows, you could even use CryptoAPI and... hmm... maybe the forking
isn't
such a bad thing after all.
Peter :-).
> I havn't tried it but i presume you could already do this with
C since
> the source fore GNUPG is in C?
It's not actually that simple to change C code
so that it can be used as a
library. At the moment (after my brief examination
of the code) it would
appear that things are largely intertwined with
main(), which is the entry
point for all C programs...
This would be need to be separated out before
the code could be turned
into an API for external use.
Cheers,
Mikal
--Michael Still (mikal@stillhq.com) - Panda PDF Generation Library (http://www.stillhq.com/panda/) - GPG Public Key at http://www.stillhq.com/mikal.asc
> library. At the moment (after my brief examination of the code)
it would
> appear that things are largely intertwined with main(), which
is the entry
> point for all C programs...
It is not that bad. main intializes the environment and takes care
of cleaning it up later and then there is just one big switch which
dispatches the commands.
There are a few g10_exit() and log_fatal() in the code shich have to
be replaced by an error return.
What about the problem of interfacing with the user. If I am developing some code to verify signatures on files nightly, then I don't want the code popping up and asking for the passphrase every time... The code to currently ask for this passphrase is in the verification routine, and would have to be moved.
Werner
-- Werner Koch GnuPG key: 621CC013 OpenIT GmbH http://www.OpenIT.de
Werner Koch responded that this would not be an option in the near future. He instead opted create a version with such capabillity for CORBA. I would like to ask him and other people to reconsider! A C-library would be so much easier to use.
This agrees with the statements I have made in this document.
I would like to wrap this C-library in as a COM component under Windows or in a KOM/OpenParts component under KDE.
-- Get your free email from www.linuxmail.orgPowered by Outblaze
> capabillity for CORBA. I would like to ask him and other people
> to reconsider! A C-library would be so much easier to use.
We are working on one - I used to call this the wrapper lib - and
some things are already working. GPA uses this lib and it is a part
of it. There is mailing list dedicated to GPA, you may want to
subscribe and ask, where you can help.
> I would like to wrap this C-library in as a COM component under
Same idea here.
> Windows or in a KOM/OpenParts component under KDE.
and ORBit/Bonobo ;)
Werner
-- Werner Koch GnuPG key: 621CC013 OpenIT GmbH http://www.OpenIT.de
> On Fri, 20 Oct 2000, Olaf Beckman wrote:
>
> > capabillity for CORBA. I would like to ask him and other people
> > to reconsider! A C-library would be so much easier to use.
>
> We are working on one - I used to call this the wrapper lib -
and
> some things are already working. GPA uses this lib and it is a
part
> of it. There is mailing list dedicated to GPA, you may want to
> subscribe and ask, where you can help.
Sorry, I'm not clear. Is this a library that exec's gpg, or a 'real' API?
Mikal
--Michael Still (mikal@stillhq.com) - Panda PDF Generation Library (http://www.stillhq.com/panda/) - GPG Public Key at http://www.stillhq.com/mikal.asc
What happened to Privacy Guard Glue? The library had a fairly easy to
use
interface could perform basic functions. However, it seems to have
died.
Anyone know?
Brandon
This archive was generated by hypermail 2b30 : Mon Oct 23 2000 - 07:34:07 EST This page has been signed.