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?
