ASDF-INSTALL for CMUCL, CLISP, AllegroCL, and LispWorks - plus tutorial
Edi Weitz
AllegroCL, and LispWorks. It is currently available from my own server
at
<http://weitz.de/files/asdf-install.tgz>
and I'd be happy if people would test it and send me bug reports.
I've also written a little tutorial for ASDF-INSTALL aimed at
"newbies" which can be found at
<http://weitz.de/asdf-install/>.
I'd like to hear (er, read) what you think about it and how it can be
improved.
Finally, I'm willing to temporarily volunteer as a "porting
maintainer", so if anybody is willing to add support for other Lisps
or make the whole shebang work on MS Windows please send patches to my
email address.
Cheers,
Edi.
Gareth McCaughan
> I have ported Daniel Barlow's ASDF-INSTALL[1] to CMUCL, CLISP,
> AllegroCL, and LispWorks.
Cool!
--
Gareth McCaughan
.sig under construc
Edi Weitz
> I have ported Daniel Barlow's ASDF-INSTALL to CMUCL, CLISP,
> AllegroCL, and LispWorks.
Thanks to Marco Baringer we now also have support for OpenMCL:
<http://weitz.de/asdf-install/>
Edi.
Steven E. Harris
> I have ported Daniel Barlow's ASDF-INSTALL[1] to CMUCL, CLISP,
> AllegroCL, and LispWorks.
I assume that if you have ASDF-INSTALL running on CLISP, then ASDF
must also work on CLISP. I checked out ASDF from CVS and tried to load
asdf.lisp using CLISP 2.32, and can't get past this error pertaining
to most of the `formatter' calls involving format strings with the
"~@<...~@:>" pattern:
,----[ CLISP loading asdf.lisp ]
| [1]> (load "asdf")
| ;; Loading file /usr/local/lib/asdf/asdf.lisp ...
| *** - Error: ~:@> not implemented
| Current point in control string:
| ~@<erred while invoking ~A on ~A~@:>
| |
| Break 1 ASDF[2]>
`----
As these `formatter' calls are pervasive throughout ASDF, it's hard to
see how CLISP users are using ASDF. Should I take this discussion to
cclan...@lists.sf.net, or can we carry on here?
--
Steven E. Harris :: seha...@raytheon.com
Raytheon :: http://www.raytheon.com
Christophe Rhodes
> Edi Weitz <e...@agharta.de> writes:
>
>> I have ported Daniel Barlow's ASDF-INSTALL[1] to CMUCL, CLISP,
>> AllegroCL, and LispWorks.
>
> I assume that if you have ASDF-INSTALL running on CLISP, then ASDF
> must also work on CLISP. I checked out ASDF from CVS and tried to load
> asdf.lisp using CLISP 2.32, and can't get past this error pertaining
> to most of the `formatter' calls involving format strings with the
> "~@<...~@:>" pattern:
It's not actually directly related to FORMATTER; see below.
> ,----[ CLISP loading asdf.lisp ]
> | [1]> (load "asdf")
> | ;; Loading file /usr/local/lib/asdf/asdf.lisp ...
> | *** - Error: ~:@> not implemented
> | Current point in control string:
> | ~@<erred while invoking ~A on ~A~@:>
> | |
> | Break 1 ASDF[2]>
> `----
>
> As these `formatter' calls are pervasive throughout ASDF, it's hard to
> see how CLISP users are using ASDF. Should I take this discussion to
> cclan...@lists.sf.net, or can we carry on here?
I inserted the FORMATTER calls as a workaround to clisp's failure to
implement ~< ~:> in regular FORMAT in released clisp versions prior to
2.32; the output from FORMATTER was not correct, but it was
acceptable.
Of course, with the new earlier error reporting, asdf does not work at
all on clisp-2.32. So the FORMATTER calls now just obscure the issue,
which is that clisp does not implement the Common Lisp standard.
However, the failure mode for clisp-2.31 and earlier was significantly
less fatal to asdf's ambition to run even on slightly non-conforming
implementations.
I suppose the good news is that now clisp is totally broken in this
respect I can remove the FORMATTERs again :-)
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Edi Weitz
> Edi Weitz <e...@agharta.de> writes:
>
>> I have ported Daniel Barlow's ASDF-INSTALL[1] to CMUCL, CLISP,
>> AllegroCL, and LispWorks.
>
> I assume that if you have ASDF-INSTALL running on CLISP, then ASDF
> must also work on CLISP. I checked out ASDF from CVS and tried to
> load asdf.lisp using CLISP 2.32, and can't get past this error
> pertaining to most of the `formatter' calls involving format strings
> with the "~@<...~@:>" pattern:
Yes, sorry I forgot about that one. I tried to compile ASDF when I
installed 2.32 shortly after its release and it didn't work - same
problem. It turned out that I was able to just load the .fas file that
I created with 2.31. Maybe I should provide this .fas file as a
workaround until CLISP can compile ASDF.
Edi.
Steven E. Harris
> I tried to compile ASDF when I installed 2.32 shortly after its
> release and it didn't work - same problem.
So is this a regressive bug in 2.32?
> It turned out that I was able to just load the .fas file that I
> created with 2.31. Maybe I should provide this .fas file as a
> workaround until CLISP can compile ASDF.
That would be helpful. I'd like to start using ASDF, so even a
temporary workaround would be sufficient.
Is this omission a known problem with CLISP 2.32? Do we need to take
up discussion the CLISP mailing list?
Edi Weitz
> Edi Weitz <e...@agharta.de> writes:
>
>> It turned out that I was able to just load the .fas file that I
>> created with 2.31. Maybe I should provide this .fas file as a
>> workaround until CLISP can compile ASDF.
>
> That would be helpful. I'd like to start using ASDF, so even a
> temporary workaround would be sufficient.
The file is available from <http://weitz.de/files/asdf.fas> - I've
also updated the docs. IIRC CLISP's FAS files are platform-neutral. I
hope I'm right. (Mine is from a Linux x86 system compiled with - I
think - 2.31.)
> Is this omission a known problem with CLISP 2.32? Do we need to take
> up discussion the CLISP mailing list?
I'm not following CLISP's development very closely but from what I
remember and from what Christophe has posted it seems like not all of
FORMAT/PPRINT is currently implemented and 2.32 raises an error where
earlier versions quietly did the wrong thing. It may even be that I'm
the guilty party - see
<http://article.gmane.org/gmane.lisp.clisp.general/6300>.
Looks like a lack of developers wishing to fix this.
Edi.
Steven E. Harris
> The file is available from <http://weitz.de/files/asdf.fas> - I've
> also updated the docs. IIRC CLISP's FAS files are platform-neutral. I
> hope I'm right.
Well, it loads fine on Cygwin/Windows 2000 with CLISP 2.32. Thanks.
I'll actually try using it later today and report back.
> Looks like a lack of developers wishing to fix this.
Indeed. Ouch.
Luis Oliveira
> The file is available from <http://weitz.de/files/asdf.fas> - I've
> also updated the docs. IIRC CLISP's FAS files are platform-neutral. I
> hope I'm right. (Mine is from a Linux x86 system compiled with - I
> think - 2.31.)
[1]> (lisp-implementation-version)
"2.32 (2003-12-29) (built 3282336750) (memory 3283083165)"
[2]> (load "asdf.fas")
...
;; Loaded file asdf.fas
T
I'm using Linux/ppc.
--
Luís Oliveira Lisp is the red pill.
Reply-To: luismbo (@) netcabo (.) pt -- John Fraser, comp.lang.lisp
Equipa Portuguesa do Translation Project
http://www2.iro.umontreal.ca/~pinard/po/registry.cgi?team=pt
Edi Weitz
> <http://weitz.de/asdf-install/>.
I've now added some Windows support for Allegro CL and LispWorks. (The
code for CLISP is also there but it has network-related
problems. Maybe someone else wants to debug this.) Make sure to
download the newest version before you try it.
Edi.
Frederic Brunel
> Thanks to Marco Baringer we now also have support for OpenMCL:
I've some troubles with this version and GnuPG. It seems that the
output of my GnuPG version is not the one expected by ASDF-INSTALL
when the key is unknown. I use version 1.2.2-1 from Fink.
One more thing, I've read your tutorial about ASDF-INSTALL and it's
fine. But I'm very curious about how you can substitute the ASDF
(operate ...) by a (require ...) on SBCL. How can I achieve the
same behavior on other implementation (like OpenMCL)? Shall I
write a simple wrapper calling ASDF?
I've noticed that on Debian, using Common Lisp Controller, you just
have to "require" the module, you don't have to call ASDF directly
to load up the system.
Thank you to help me understand how these systems are working.
--
Frederic Brunel
Edi Weitz
> I've some troubles with this version and GnuPG. It seems that the
> output of my GnuPG version is not the one expected by ASDF-INSTALL
> when the key is unknown. I use version 1.2.2-1 from Fink.
I can't help in this case. I hope Marco is reading this.
> One more thing, I've read your tutorial about ASDF-INSTALL and
> it's fine. But I'm very curious about how you can substitute the
> ASDF (operate ...) by a (require ...) on SBCL. How can I achieve
> the same behavior on other implementation (like OpenMCL)? Shall I
> write a simple wrapper calling ASDF?
I'm not an SBCL expert but if you look at the source of ASDF you'll
notice that it makes use of a variable called
SB-EXT:*MODULE-PROVIDER-FUNCTIONS*, so obviously SBCL is exposing its
PROVIDE/REQUIRE mechanism to programmers. AFAIK most other Lisps don't
do that.
> I've noticed that on Debian, using Common Lisp Controller, you
> just have to "require" the module, you don't have to call ASDF
> directly to load up the system.
I think this is possible because MK:DEFSYSTEM redefines REQUIRE (which
seems to work but is probably illegal w.r.t. the ANSI standard). Look
at the MK:DEFSYSTEM sources and search for occurences of
*DONT-REDEFINE-REQUIRE*.
HTH,
Edi.
Frederic Brunel
>> I've some troubles with this version and GnuPG. It seems that the
>> output of my GnuPG version is not the one expected by ASDF-INSTALL
>> when the key is unknown. I use version 1.2.2-1 from Fink.
>
> I can't help in this case. I hope Marco is reading this.
It's ok, I've just get e-mail from him... I'll send him a backtrace
of the error.
[...]
> I'm not an SBCL expert but if you look at the source of ASDF you'll
> notice that it makes use of a variable called
> SB-EXT:*MODULE-PROVIDER-FUNCTIONS*, so obviously SBCL is exposing
> its PROVIDE/REQUIRE mechanism to programmers. AFAIK most other Lisps
> don't do that.
Ok, I understand. I was thinking about this kind of thing.
>> I've noticed that on Debian, using Common Lisp Controller, you
>> just have to "require" the module, you don't have to call ASDF
>> directly to load up the system.
>
> I think this is possible because MK:DEFSYSTEM redefines REQUIRE (which
> seems to work but is probably illegal w.r.t. the ANSI standard). Look
> at the MK:DEFSYSTEM sources and search for occurences of
> *DONT-REDEFINE-REQUIRE*.
I see. Maybe I can do the same for my local configuration. I know
it's generally a bad idea to redefine a core function, but for my
personal use, I guess it should be ok.
Well, thanx Edi for your answer.
--
Frederic Brunel
Marco Antoniotti
Edi Weitz wrote:
>> I've noticed that on Debian, using Common Lisp Controller, you
>> just have to "require" the module, you don't have to call ASDF
>> directly to load up the system.
>
>
> I think this is possible because MK:DEFSYSTEM redefines REQUIRE (which
> seems to work but is probably illegal w.r.t. the ANSI standard). Look
> at the MK:DEFSYSTEM sources and search for occurences of
> *DONT-REDEFINE-REQUIRE*.
REQUIRE and PROVIDE are deprecated in the ANSI standard.
MK:DEFSYSTEM3.x does redefine them (in a convoluted way), but it is
better not to rely on it.
AFAIAC, any machinery that relies on these two functions is bound to
have shortcomings.
Cheers
--
Marco
Frederic Brunel
> REQUIRE and PROVIDE are deprecated in the ANSI standard.
> MK:DEFSYSTEM3.x does redefine them (in a convoluted way), but it is
> better not to rely on it. AFAIAC, any machinery that relies on
> these two functions is bound to have shortcomings.
You're right, I've just noticed it in the hyperspec. So, what's the
good recommendation about module loading? There is no a standard
way to replace the REQUIRE/PROVIDE mechanism?
Basically, you should remove all calls to REQUIRE inside modules and
use an external tool like ASDF to do the job, right?
--
Frederic Brunel
Christophe Rhodes
Deprecation does not mean disappearance. I wasn't there at the time,
but my understanding of the deprecation of PROVIDE and REQUIRE wasn't
that there was no need for a mechanism like that, but that the
mechanism as standardized wasn't it.
Using the one-argument form of PROVIDE and REQUIRE in code designed to
be portable probably isn't a terribly good idea; on the other hand,
programs that run in known environments in which the behaviour is
documented shouldn't eschew the use of such mechanisms just because
ANSI says "might be removed in the next revision of the standard". I
hope people aren't ignoring the use of REMOVE-IF-NOT just because it
says "deprecated", similarly.
Don Geddis
> Deprecation does not mean disappearance. [...]
> programs that run in known environments in which the behaviour is
> documented shouldn't eschew the use of such mechanisms just because
> ANSI says "might be removed in the next revision of the standard".
But what does "depreciated" mean for you, then?
Surely the goal is to remove such items from the language (in a future
version). And surely they would have been removed in the current version,
except for backward compatibility with legacy code.
Standards writers generally use the "depreciated" label to acknowledge that
it would be costly to immediately change all legacy code, and yet to request
that any _future_ code not use the features. That way, the cost is
considerably reduced at the next standardization, since much legacy code will
have simply expired and/or no longer have value, while the newest code won't
use the features.
If you use the features anyway, knowing this future, aren't you defeating the
purpose?
It seems to me that it's basically the same as using non-standard
implementation-specific extensions. I.e., you're committing to portability
problems across implementions, operating systems, and especially into the
future. Kind of a different expectation than writing a portable program
under the main part of the standard, where you might expect future standards
efforts and implementors to at least have some concern over the problems that
changes will cause your legacy code.
> I hope people aren't ignoring the use of REMOVE-IF-NOT just because it says
> "deprecated", similarly.
As I recall, sentiment on this one may have changed after the ANSI standard.
I would bet that it is likely to be "un-depreciated" if there ever comes some
future standards effort.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ d...@geddis.org
I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it,
and I just hate it. -- Clarence Darrow
Rob Warnock
+---------------
| But what does "depreciated" mean for you, then?
[That the value recognized for tax or net-worth purposes has declined???
I think you meant "deprecated".]
The dictionary says that "deprecate" means "play down" or "make little of"
or "express disapproval of", but since this is in the context of Common Lisp,
why not look directly to the standard:
<URL:http://www.lispworks.com/reference/HyperSpec/Body/01_h.htm>
1.8 Deprecated Language Features
Deprecated language features are not expected to appear in future
Common Lisp standards, but are required to be implemented for
conformance with this standard; see Section 1.5.1.1 (Required
Language Features).
Conforming programs can use deprecated features; however, it is
considered good programming style to avoid them. It is permissible
for the compiler to produce style warnings about the use of such
features at compile time, but there should be no such warnings at
program execution time.
I read this as saying that deprecated features are *at most* an issue of
style [about which there are arguments forever]. It is certainly *not* an
issue of conformance, since conforming implementations are *required* to
implement them and conforming programs are explicitly permitted to use them.
For myself, I tend to use REQUIRE/PROVIDE for single-file "library"
features, whether local or imported, that various random *other*
programs might want to access -- much like using "#include <foo.h>"
and "-lfoo" in C -- particularly if the using program is small or
lightweight, such as a Unix shell script or a CGI script. E.g., most
of my CGI scripts tend to start with:
;;; CGI SCRIPTS W/ SQL -- Standard prologue
(eval-when (:compile-toplevel :load-toplevel :execute)
(require :utils) ; Misc. local hacks I like to have around.
(require :htout) ; Tim Bradshaw's HTML macros.
(require :uri) ; More local hacks (CGI support stuff).
(require :pg)) ; Eric Marsden's PostgreSQL binding
Conversely, I tend to use ASDF for anything that smells more like a
"system" (such as a whole Lisp application server), and in that case
subsystems like HTOUT or PG get loaded via ASDF instead of REQUIRE.
Your chosen style(s) may well differ from mine.
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Christophe Rhodes
> Christophe Rhodes <cs...@cam.ac.uk> writes:
>> Deprecation does not mean disappearance. [...]
>> programs that run in known environments in which the behaviour is
>> documented shouldn't eschew the use of such mechanisms just because
>> ANSI says "might be removed in the next revision of the standard".
>
> But what does "depreciated" mean for you, then?
Picking up on your mistake here would normally be petty, but since
you're asking, depreciation is the decline in value of an asset
because of its age. The excuse for such pettiness is that you're
asking about the meaning of a technical term used in a quasi-legal
document, so please make an effort to get it right :-)
I think "deprecated" means "might be removed or altered in the next
revision of the standard." And the philosophy behind nevertheless
using such deprecated features in implementations which document their
use is (a) the next revision of the ANSI standard looks further away
now than it did in 1994; (b) deprecated features won't necessarily be
removed in the revision, as a lot of water has passed under the bridge
since then, and (c) if an implementation commits to a particular
meaning, it's unlikely that the implementation will remove the
functionality unless it is so mandated by the next revision -- the
chances are that it could be maintained as an extension to the
language.
> Surely the goal is to remove such items from the language (in a future
^
+- or alter
> version). And surely they would have been removed in the current version,
> except for backward compatibility with legacy code.
> [...]
> If you use the features anyway, knowing this future, aren't you defeating the
> purpose?
I'm confident that my use of PROVIDE won't cause a noticeable cost to
the Lisp community or indeed myself, even in the apocalyptic scenario.
> It seems to me that it's basically the same as using non-standard
> implementation-specific extensions. I.e., you're committing to portability
> problems across implementions, operating systems, and especially into the
> future. Kind of a different expectation than writing a portable program
> under the main part of the standard, where you might expect future standards
> efforts and implementors to at least have some concern over the problems that
> changes will cause your legacy code.
Yes. And I hope that people are using non-standard
implementation-specific extensions, because otherwise we won't have
any Lisp webservers, or Unicode-aware Lisps, or Lisps with workable
compiler macro support, or Lisps with high-performance user-extensible
streams, or Lisps with graphical user interface bindings, or Lisps
with foreign function support, or Lisps with useful debugging tools
like an advanced tracer or a single stepper, or indeed much of
anything. Do you use your lisp's debugger or inspector? Its
behaviour is mostly non-standard.
>> I hope people aren't ignoring the use of REMOVE-IF-NOT just because it says
>> "deprecated", similarly.
>
> As I recall, sentiment on this one may have changed after the ANSI standard.
> I would bet that it is likely to be "un-depreciated" if there ever comes some
> future standards effort.
And how do you know that sentiment has not changed on PROVIDE and
REQUIRE? Or, more to the point, that sentiment won't change in the
next X years before the standard is revised?
Joe Marshall
> As I recall, sentiment on this one may have changed after the ANSI standard.
> I would bet that it is likely to be "un-depreciated" if there ever comes some
> future standards effort.
Deprecating REMOVE-IF-NOT was an error.
--
~jrm
Paul F. Dietz
> Deprecating REMOVE-IF-NOT was an error.
Yes, but it would be nice if implementations did not penalize the use
of the (remove-if (complement <fn>) ...) idiom.
Paul
Rob Warnock
+---------------
Sounds like a job for compiler macros.
rif
So does anyone use ASDF-INSTALL? I read the manual, and it seems
great, except that the security tradeoffs are quite painful. Say for
example I want to automatically install Kevin Rosenberg's UFFI package
with ASDF-INSTALL. I have at least three options I can see. The
first choice is that I disregard the security issues completely, and
hope that noone has altered the world-writeable cliki page. The
second choice is that I manually track down the actual location of the
package (i.e., I make the reasonable decision that I'm willing to
trust uffi.b9.com even though I'm not willing to trust www.cliki.net,
because Kevin Rosenberg is well-known and his site is not known to be
world-writeable), download Kevin's key myself, then run ASDF-INSTALL.
And the third choice is that while I'm at uffi.b9.com, I just go ahead
and download the uffi package manually, and if I care, check that the
signature matches.
What advantage does the second approach give me over the first? Am I
missing something obvious here? I want to like ASDF-INSTALL, but so
far I haven't figured out a way for it to be sufficiently convenient.
Furthermore, since noone is actually auditing the code anyways, AFAICT
there is nothing stopping anyone from making a package that supposedly
does foo, but instead (in addition) contains arbitrary malicious code,
then signing this package correctly. So again, one is reliant on
knowing who the author of the package is, and explicitly deciding to
trust them because they are known, or auditing the source oneself
before using it. In other words, the "obvious" approach of "I want
package X, I'll add the author of package X's key to my ring" doesn't
really seem much more secure than just telling ASDF-INSTALL not to
bother with the check at all.
I guess I'm not sure what actual security problem using encryption
keys here is designed to solve. Maybe the problem where someone who
is known initially provides a real package, and that package is being
updated frequently (so it's less tedious to add the person to your
keyring then just to keep downloading their package), and then someone
edits CLiki to point at a malicious version? Maybe?
Off the cuff, it seems that what is needed is a non-world-writeable
page, along with someone who's willing to be an authority, at least
for a number of packages by well-known authors. Or more likely, I'm
just missing something obvious, as usual.
rif
ps. How do CPAN (or other similar systems) handle this?
niko...@random-state.net
> So does anyone use ASDF-INSTALL?
Yes.
If you install software written by someone else you need to trust _someone_:
the author, or someone else who says that the sofware is safe. The
asdf-install solution is to let package authors sign their packages, and you
choose whom to trust.
You don't need to track down the original package -- let asdf-install handle
that: the gpg stuff is there to provide the security. If someone repoints a
CLiki page to a maliscious package then the signatures won't match the real
authors signature, and shouldn't be in your trusted uids database either.
You should be fairly safe as long as you:
1) Pay attention to whom you tell asdf-install to trust.
2) Don't "install-anyways" if asdf-install tells you
there's a problem.
An extra mile you can go is trying to establish a proper web of trust, or at
least a "pyramid of trust". Your local Debian people are probably a good
starting point.
Of course, if someone you did trust does the nasty you're fried.
Cheers,
-- Nikodemus
rif
> 1) Pay attention to whom you tell asdf-install to trust.
> 2) Don't "install-anyways" if asdf-install tells you
> there's a problem.
But what do you mean by "asdf-install telling me there's a problem?"
AFAICT, unless the person who wrote the package's key is in my keyring
AND I've established a trust relationship with them, then ASDF-INTSALL
will ALWAYS say there's a problem.
How do you actually deal with this? Do you go get people's keys and
put them in your keyring, or do you say "Ah, I know this package was
written by Kevin Rosenberg. I trust Kevin Rosenberg, and it seems
unlikely to me that someone mucked with the cliki page, and therefore
it seems likely to me that ASDF-INSTALL is given me a package that was
actually written by him." Or some other method? If it's the first
method, then I suggest that using ASDF-INSTALL is no more "automated"
than simply downloading packages directly from people's pages, unless
you're downloading a lot of packages signed by one individual. If
it's the second, then I suggest that rather than using the idea of
signed packages to provide a false sense of security, we'd be better
off if various people (there are a number I'd trust right here on
c.l.l., given all the help I've been given in the past) simply put up
their own, non-world-writeable pages, pointing to collections of
packages by people *they* trust, and then adding a facility to
ASDF-INSTALL to allow us to point at those pages. Or perhaps there is
some other method you use that I'm missing?
Again, I'm *not* any kind of expert on security (as I'm sure will be
obvious from this posting), I'm just trying to understand how people
are using ASDF-INSTALL.
Cheers,
rif
niko...@random-state.net
> But what do you mean by "asdf-install telling me there's a problem?"
> AFAICT, unless the person who wrote the package's key is in my keyring
> AND I've established a trust relationship with them, then ASDF-INTSALL
> will ALWAYS say there's a problem.
Not quite.
Establishing a web of trust, while good and recommended, isn't strictly
speaking necessary. A web of trust usually means that you trust the person
behind the key to really be who he claims to be, which is largely orthogonal
to whether or not you trust that person to write non-maliscious software.
You can treat a public key as an opaque identity associated with a source of
software.
Example:
Alice is a software author who writes dependable, non-maliscious software.
Bob is software author who writes essentially good software, but is sloppy
in his own seurity, and the packages he uploads are occasionally
trojaned.
Clark is an evil person, whose pretended online personality has nothing to
do with his real identity. His long term plan is to gain the trust of
millions and then misuse it by sneaking evilware onto their computers.
Compare the situations using the persons public key as an opaque
electronic identity vs. having a web of trust:
Alice: No essential difference.
Bob: If your box is compromised you might try to sue for damages.
Clark: You're protected because you refuse to download software
from authors you don't have a web of trust to.
So having a web of trust only protects you from those maliscious authors who
hide behind faked identities. Using the opaque identity gives you identical
seurity vs. tampered cliki redirects, etc. as a web of trust. I, personally,
don't regard it as necessary for installing stuff -- your mileage will wary
depending on your security needs.
Also, getting a web of trust to persons X is most of the time quite doable
if it's important enough to warrent a little effort. A fair number of free
lisp developers are decently connected, and a few are extremely well
connected -- if you get to the Debian web of trust you probably have a web
of trust to most authors.
Now, you apparently disregarded my allusion to the "pyramid of trust", which
is essentially a flawed version of web of trust, but very easy to establish,
and still somewhat better than nothing. You can eg. decide to trust for
installation purposes all keys signed by keym...@common-lisp.net, or
whomever, thusly gaining multiple weakly trusted keys in one whopping step.
If the key you decide to trust is an "institutional one" like the
aforementioned keym...@common-lisp.net the net effect is essentially the
same as if there was a central authority, you just get to decide who it is
for you.
> Do you go get people's keys and put them in your keyring,
Yes. This is _not_ a chore: the keys are on the keyservers and gpg knows how
to fetch them. Unless there are multiple keys (hasn't happened to me yet)
I live with the assumption that it's the right one. If the key is not on a
keyserver I fetch it from the authors webpage or whatever: it's a
one-time-job, as opposed to installation which will happen with every new
version.
I don't sign the keys trusted, but let asdf-install to add them to its own
trusted uids collection.
> method, then I suggest that using ASDF-INSTALL is no more "automated"
> than simply downloading packages directly from people's pages, unless
> you're downloading a lot of packages signed by one individual.
Bull. As said, GPG knows how to pull keys, and pulling keys is a one time
thing, as opposed to installation. Furthermore, as it happens the actual
number of people writing asdf-installable packages is rather small compared
to the number of packages -- so you are very very likely to install multiple
packages by the same author.
The real value of asdf-install for me is in tracking dependencies.
-- Nikodemus
niko...@random-state.net
> Yes. This is _not_ a chore: the keys are on the keyservers and gpg knows how
> to fetch them.
One thing I forgot to mention: you can fetch all keys currently signed by
the keym...@common-lisp.net (the common-lisp.net admimistrative key) at
one step from:
http://common-lisp.net/keyring.asc
That should get you started. ;)
Cheers,
-- Nikodemus
rif
Thank you so much for taking the time to write such a detailed and
informative post. I agree that your strategy of getting keys into the
keyring, and then telling ASDF-INSTALL to trust these keys seems like
a reasonable way to go --- and does have real benefits (dependency
management, version updates) over downloading the packages directly.
I just started with GPG today, and I was not aware of the concept of
"keyservers" before your post (the documentation I started with, the
"GPG Mini-Howto", doesn't seem to mention them). This seems like it
will really help automate the process of getting the appropriate keys.
I will investigate this further.
Perhaps when I figure it out a little better, I can propose a slight
addition to the ASDF-INSTALL "tutorial."
Cheers,
rif