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.
> 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 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?
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.