Daniel Barlow | 4 Jun 05:14 2003
Picon

[sucky] Automatic download tool.


I've just committed a first cut at a tool which can be used to
download and install cclan packages automatically.  It's a hack, but
it's a low-overhead hack that can easily be installed.  Herewith a
list of features/nonfeatures

 * finds package locations by referring to the :(package) link on the
   given cliki page

 * builtin http (almost) client.  Copes with proxies, unless they need
   to be authenticated to

 * attempts to pull detached pgp signatures (foo.asc files) and verify
   them against the download.  probably quite important when your
   download location can be changed by anyone who can edit a cliki page   

 * doesn't yet, however, verify that the package signature is from
   someone whose Lisp you trust, just that you have them on your pgp
   keyring

 * downloads files, sets asdf to compiling them.  chases dependencies
   where the dependencies are not present on the system

 * does/knows absolutely nothing about versions 

 * presently sbcl-only.  requires tar and gpg, but no dependencies on
   any Lisp modules other than thosre that come with sbcl.  not
   elegant, but it can be used to bootstrap a more elegant solution,
   which will probably need more libraries and stuff.

(Continue reading)

Daniel Barlow | 9 Jun 14:40 2003
Picon

Re: [Cclan-commits] CVS: asdf asdf-install.lisp,1.3,1.4


Christophe Rhodes <csr21 <at> cam.ac.uk> writes:

>> +	 (if (string-equal package-name-or-url "http://"
>> +			   :end1 7)
>
> Will break for package-name-or-url smaller than seven characters.

Duh.  Yes.  Thanks.

> There is an idiom for this, fortunately:
>   (if (= (mismatch package-name-or-url "http://") 7)
>       ...

Applied

-dan

--

-- 

   http://www.cliki.net/ - Link farm for free CL-on-Unix resources 
Daniel Barlow | 9 Jun 21:35 2003
Picon

asdf-install and pgp


[ this email goes to cclan-list because packaging and installation
tools are the kind of thing it's about, and to Miles and Edi
personally because they now have asdf-installable versions of their
software packages linked fron CLiki ]

If we are to automatically download and run code from freely-editable
links on the internet, I think that some form of authentication of the
code is required, and PGP to verify the source is a good place to
start.  It does open up a whole "who do you trust" can of worms,
though, in that the effort you might once have spent finding sources
you now have to spend getting and verifying PGP keys

I've just retrieved Miles' key from the keyservers 

  pub  1024/01F53D51 2002-06-04            
	   Fingerprint=E323 24E0 932E 9419 797E D8B3 5382 6AFF 01F5 3D51 

(not the same key as is posted on the SBCL web page for him,
incidentally) and it matches all the PGP-signed mail I've had from him
over the past few months , so I'm thinking that probably merits a "(2)
I have done casual checking" signature.  (I reserve (3) for physical
meeting with proof of id).  I don't think that approach scales,
though, and it's certainly not much good for new users

Any ideas?  One thought that occurs to me is that there seem to be
Debian developers in many places; if we could all get keys signed by
well-connected Debian developers, that might join the dots between us
a bit.  Still doesn't solve the new-user problem, though

(Continue reading)

Edi Weitz | 9 Jun 21:47 2003
Picon

Re: asdf-install and pgp

Daniel Barlow <dan <at> telent.net> writes:

> [ this email goes to cclan-list because packaging and installation
> tools are the kind of thing it's about, and to Miles and Edi
> personally because they now have asdf-installable versions of their
> software packages linked fron CLiki ]
> 
> If we are to automatically download and run code from
> freely-editable links on the internet, I think that some form of
> authentication of the code is required, and PGP to verify the source
> is a good place to start.  It does open up a whole "who do you
> trust" can of worms, though, in that the effort you might once have
> spent finding sources you now have to spend getting and verifying
> PGP keys
> 
> I've just retrieved Miles' key from the keyservers 
> 
>   pub  1024/01F53D51 2002-06-04            
> 	   Fingerprint=E323 24E0 932E 9419 797E D8B3 5382 6AFF 01F5 3D51 
> 
> (not the same key as is posted on the SBCL web page for him,
> incidentally) and it matches all the PGP-signed mail I've had from
> him over the past few months , so I'm thinking that probably merits
> a "(2) I have done casual checking" signature.  (I reserve (3) for
> physical meeting with proof of id).  I don't think that approach
> scales, though, and it's certainly not much good for new users
> 
> Any ideas?  One thought that occurs to me is that there seem to be
> Debian developers in many places; if we could all get keys signed by
> well-connected Debian developers, that might join the dots between
(Continue reading)

Daniel Barlow | 9 Jun 22:07 2003
Picon

Re: asdf-install and pgp


Miles Egan <miles <at> caddr.com> writes:

> FreeBSD and Gentoo solve this problem by checksumming the source
> package.  Could we accomplish this simply by adding an md5sum field to
> the download link on the cliki page?

But anyone who wants to edit the download link and make it point to
their own malicious code somewhere else can also edit the md5 on the
page to correspond to their trojanned package.

(Actually this is still a problem with asdf-install in that they can
sign their own malicious package with their own key and if you have
keys for such bad people on your keyring it'll get installed anyway.
What we _really_ need is some way of saaying "I trust content from
this person", not just "I trust this person is who he says he is".
But at least then you know afterwards who was responsible for
subverting your system ...)

-dan

--

-- 

   http://www.cliki.net/ - Link farm for free CL-on-Unix resources 
Daniel Barlow | 9 Jun 22:12 2003
Picon

Re: asdf-install and pgp


Edi Weitz <edi <at> agharta.de> writes:

> One other thing: I just noted that you seem to use '_' (underline) to
> separate the name of the package from its version number. I currently
> use '-' (hyphen) - does that mean it won't work if I release a new
> package? No problem for me to switch to '_' but I'll have to ask Kevin
> if it breaks his Debian package.

Really shouldn't make a difference, actually.  '_' is less likely to
be part of a package name, is all.  The important thing is that
different versions unpack into different directories, so that new
possibly broken code isn't unpacked over old working code.  If
anything goes wrong the user can then fix it by manual symlink
manipulation in their systems/ directory

-dan

--

-- 

   http://www.cliki.net/ - Link farm for free CL-on-Unix resources 
Christophe Rhodes | 11 Jun 12:37 2003
Picon
Picon

Re: ASDF: alternative system configurations

Nikodemus Siivola <tsiivola <at> cc.hut.fi> writes:

> How should I deal with alternative system configurations with ASDF? My
> system can function both with or without CL-SDL, but the system is slightly
> different when it is not present:
>
>  window.lisp <-- needs SDL
>  render.lisp <-- needs window.lisp if we have SDL
>
> Currently I have solved this by having two alternative system definitions,
> detecting the presence of SDL before calling ASDF, and then loading the
> correct system. As far as solutions go it works, but is butt ugly.
>
> Is there a way to handle this with a single system-definition?

Apologies for the appallingly late reply; maybe you've already solved
this, or given up entirely, or something, but just in case this
information is still useful, I think I know how to do this.  There is
good news and bad news.

The bad news is that this can't be done without a *feature*, I think.
On the other hand, said feature doesn't have to be provided by cl-sdl;
you can do something like
  (when (find-package "SDL")
    (pushnew :my-package-has-found-sdl *features*))
Sadly, I can't see a way currently to avoid polluting the global
*features*, unless you're in the habit of compiling your .asd files,
in which case it could be done on (eval-when (:compile-toplevel) ...)

Anyway, on with the good news: on the assumption that the above
(Continue reading)

Christophe Rhodes | 11 Jun 12:52 2003
Picon
Picon

Re: ASDF: alternative system configurations

james anderson <james.anderson <at> setf.de> writes:

> not the original question, but take a situation where i have four system
> components a,b,c,d and for the purposes of compiling the system the depandancy is
>
>        a
>       / \
>       b c
>       \ /
>        d
>
> which means that the builder needs to specify either a and b, or a and c to
> build. on the other hand, when it comes to documenting or releasing, one would
> like to specify a and b and c and not have to worry about what
> conditionalization has done to the effective expression of the system structure.

Again, a late response; I've only just begun pushing the boundaries of
"normal" asdf use; (untested):

(defsystem foo
  :components 
  ((:file "a")
   (:module "bar"
      :depends-on "a"
      :components
      ((:file "b" :in-order-to (compile-op (feature :use-b)))
       (:file "c" :in-order-to (compile-op (feature :use-c))))
      :if-component-dep-fails :try-next)
   (:file "d" :depends-on "bar")))

(Continue reading)

Erik Enge | 24 Jun 16:22 2003
Picon

Link to Large-Systems.html in ASDF README incorrect.

KMP's stuff is now at nhplace.com, the link should be:

  <http://www.nhplace.com/kent/Papers/Large-Systems.html>

Erik.

-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
David Kleiner | 26 Jun 06:19 2003
Picon

cl-http+asdf

Hi,

As a little project of mine to get a "feel" of what a larger lisp
system may look like, I've been trying to asdf'y CL-HTTP system.

My lisp awareness is limited so please bear with me <g>

Here is my problem:

---

* (asdf:operate 'asdf:load-op 'cl-http)
; /home/lisp/tools/asdf/systems/cl-http.asd into
; #<The ASDF1339 package, 0/9 internal, 0/9 external>
; Loading #p"/home/lisp/tools/cl-http-70-159-devo-asdf/cmucl/server/server.asd".

File-error in function TRUENAME:
   The file "HTTP:mcl;server;resources.lisp" does not exist.

Restarts:
  0: [RETRY-COMPONENT] ASDF::RETRY-COMPONENT
  1: [SKIP-COMPONENT ] ASDF::SKIP-COMPONENT
  2: [ABORT          ] Return to Top-Level.

Debug  (type H for help)

(TRUENAME #.(logical-pathname "HTTP:mcl;server;resources.lisp"))
Source: Error finding source: 
Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM:  Source file no longer exists:
  target:code/filesys.lisp.
(Continue reading)


Gmane