Hacker News Reader

Comment by jgerrish | Hacker News Reader

I posted previously about SBCL and quicklisp. Great ecosystem. I'm still learning but it's usually fun to work in.

I made some recommendations about quicklisp using http by default and how to lock it down.

I don't know if those are good recommendations anymore. I couldn't manage to follow them myself. I couldn't keep up and my patch approach didnt work.

So, I don't know the best approach with that problem, but I was too confident in my post about security suggestions.

View on HN

Check out ocicl as an alternative to quicklisp if you are concerned about security. Code is distributed using the OCI ecosystem (https by default, proxies work, sigstore integration, etc). https://github.com/ocicl/ocicl

Quicklisp, ironically, only updates once a month. It's managed like a Linux distro. That means the client has a full index of every library in the registry, and knows the hash of every file it may download.

I am pretty sure quicklisp checks the hashes it downloads. Hence, the only security issue with using HTTP seems to be that middleman can see what you've downloaded... if they try to change it in any way, the quicklisp client will reject the download as far as I know (though I haven't checked the code).

Do you believe this is not sufficient, and why?

Man-in-the-middle attacks. But equally important, many secure environments won't allow outbound http connections.

What kind of mitm? The attacker cannot modify what you get. You leak the list of packages you download, but I don't think https by itself would have helped — host and filesize would be known, and that should be enough.

https also provides secure authentication, not merely encryption. The encryption part also guarantees the authentication part by proving that the stream can not have been modified.

In order to meet this guarantee for the scheme you're discussing, the hashes themselves need to have a tamper evident. What is this tamper evident?

Yes, that's clear.

I'm not very familiar with how quicklisp works. I thought that “updates once a month” implies a separate update channel (distribution, ...).

Looking at the relevant issue, https://github.com/quicklisp/quicklisp-client/issues/167 , it's not clear that even hashes are in place.

I recently found out that most Nix fetchers use https, but do not actually do verification (`curl --insecure` or equivalent libcurl settings). Channel updates do verify and include hashes, so the overall chain is authenticated.

Reply on news.ycombinator.com