gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] crypto signing take 2


From: Tom Lord
Subject: Re: [Gnu-arch-users] crypto signing take 2
Date: Wed, 10 Dec 2003 19:21:07 -0800 (PST)

    > From: Andrew Suffield <address@hidden>

    > On Mon, Dec 08, 2003 at 02:11:46PM -0800, Tom Lord wrote:
    > > [*] It's funny, from my perspective, when people talk about using
    > >     q-agent in order to keep the "TCB" small.   Geeze, I only had to=20
    > >     install about 10MB of new source (including an out of date version
    > >     of one package) just to get it to compile.

    > >     And all that for a server program and wrapper that should be, at
    > >     _most_, 10 pages of very portable unix code.

    > Common impression, but it's not really accurate. The vast majority of
    > that stuff was to get the
    > entirely-independent-why-is-this-shipped-in-the-same-package gtk
    > passphrase input box to compile. The *important* stuff only depends on
    > glib, which is actually fairly small in its own right - it's mostly
    > data structure crap (and no transitive dependencies of note).

Not quite true.  I in fact don't and probably can't get gtk compiled
on my box.   My headaches revolved around glib (for which a
non-current version was required), gettext, and iconv.

I completely and utterly agree with:

        > entirely-independent-why-is-this-shipped-in-the-same-package

about the GTk stuff.

I'd have liked to see the core part of q-agent _not_ rely on glib
(especially given that it doesn't even configure against the latest
glib), _not_ try to be fancy with messages, and to be written in a
style that looks like something you'd find in /usr/src on a ca. 1989
BSD box.   Then I might have some confidence that the "many eyeballs"
could meaningfully bless it into the "TCB".


    > The significant code in quintuple-agent comes in at slightly over 1k
    > lines physical, or slightly under by SLOC. The only significant thing
    > used by that code from glib is the hashtable implementation.

Yeah, but nobody is watching that dependency tower.   Who knows what
the hashtable implementation in glib will depend on tomorrow.

I'm a hyprocite, of course, in the sense for a dinky little tla
implementation I drag in all of libhackerlab.   But why I think that
that's a good choice and that we should all gang up to replace libc in
future code with a hackerlab descendent -- well, that's a flamewar for
another day.

-t





reply via email to

[Prev in Thread] Current Thread [Next in Thread]