Comment by armitron | Hacker News Reader

Comment by armitron | Hacker News Reader

Parent Full thread

Quicklisp is not panacea, even though it simplifies matters to a substantial degree for people new to Common Lisp.

On the other hand Quicklisp has serious issues:

+ Minimal if any documentation of internals.

+ A substantial chunk of the codebase can only be described as spaghetti code. To make matters even worse, most functions lack documentation strings. A sad state of affairs given the interactive and self-documenting nature of CL.

+ Is vulnerable to man-in-the-middle attacks since it verifies neither certificates nor checksums. This means that using Quicklisp can get you owned. Unacceptable these days.

+ Operates over a 'curated repository' model that Xach is managing. The repository has been found to be vulnerable to man-in-the-middle attacks in the past since packages were fetched over plain HTTP or git://. Even if that wasn't the case, it's yet another element in the chain of things to trust.

+ Few if any people besides Xach are working on quicklisp-client to mitigate these issues. Lack of documentation and spaghetti code is not helping to attract new talent.

+ Xach is employed by Clozure Associates. I understand that they've allotted him some time to work on Quicklisp while on the job, but it's still a side-project. Look at the number of open issues at Github. Many have been there for years.

For these reasons, I don't use Quicklisp myself. I also advocate against it to friends and colleagues who share my views on software distribution mechanisms.

I hope to improve the documentation and security of Quicklisp in the next few months. It will depend on funding.

The core of Quicklisp is in dist.lisp. Understanding the protocol of the generic functions at the start of that file will help clarify Quicklisp as a whole. Almost everything else Quicklisp does is in support of that protocol.

That's great to hear. On your donations page you have indicated that there will be a special fundraiser. If that's not the case still, I suggest you remove it as people could be waiting for it and not donating.

AFAIK, Xach is no longer working for Clozure. Since 2015.

One can donate for Quicklisp work, even for specific features:

https://www.quicklisp.org/donations.html

Xach is working on a fundraiser effort to get it out of beta.

https://twitter.com/quicklisp/status/798316176082354176

> To make matters even worse, most functions lack documentation strings

It's not that there are no documentation strings. Example:

https://github.com/quicklisp/quicklisp-client/blob/master/qu...

> I also advocate against it to friends and colleagues who share my views on software distribution mechanisms.

It would be better to advocate to friends to help improve it.

> Its not that there are no documentation strings. Example:

At the end of the day it's the quality of documentation that matters. He did document some of the generic functions but in manner that is not very productive, as the doc strings are both minimal and don't let you get an idea of how the thing fits in the overall picture.

I would bet money even Xach would be confused going back to that codebase after a year of non-exposure.

I spent an afternoon trying to figure out how to add cryptographic checksum verification support. One could say the simplest of tasks. After a few hours of diving into that codebase, a picture of the whole was not emerging. Eventually I gave up in frustration. This is not ideal.

Well, I would usually discuss things with the original author instead of figuring all out by myself.

While I agree with most of the issues you report, what are thea alternatives ? I think Quicklisp is the lesser evil.

Well for some of us the lesser evil is unacceptable. The rest will happily use Quicklisp.

If I had to guess however, I would say that the vast majority of Quicklisp users are not aware of the tradeoffs they are making. It's troubling that none of the security implications I mentioned are listed or even hinted at, in the Quicklisp site https://www.quicklisp.org/beta/release-notes.html or anywhere in the Quicklisp documentation.

One alternative is to improve Quicklisp. I don't want to be seen as blaming Xach here, but he's solely responsible for the lack of documentation. For CL docstrings especially, their absence is unfathomable for a core project that is positioned for wide usage. Every function, method and dynamic variable should have a docstring. You don't add these after the fact, you add them when you're writing the code.

If Xach improves the documentation situation, people will step in and start fixing issues.

The HTTP issue I guess can be easily solved. In fact if I try to manually download the same package over HTTPS (I mean packages with url from beta.quicklisp.org) it works so maybe th e solution is very simple

The solution is far from simple if you want to do it in 100% Common Lisp as there's no CL HTTP client that can verify certificates. Maybe possible with drakma and cl+ssl and a custom configuration of the latter and a native OpenSSL library, and I still have doubts.

That is shocking! I do not know well the common lisp community. Am I write in thinking that racket has an http client that can verify certificates or am I underestimating the complexity of ssl?

But then, for a practical solution, why do it in 100% Common Lisp?

Portability to various OSes and environments and working immediately out-the-box with no extra dependencies.

That said, the patches I sat down to do would re-use native executables (md5, sha1) and wget/curl.

Reply on news.ycombinator.com