4 ms·

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 quicklis

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.

atgreen 3y ago
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 https://github.com/ocicl/ocicl
brabel 3y ago
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?
- atgreen 3y ago
  Man-in-the-middle attacks. But equally important, many secure environments won't allow outbound http connections.
  - akho 3y ago
    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.
    - isityouyesitsme 3y ago
      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?
      - akho 3y ago
        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 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.

atgreen 3y ago

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 https://github.com/ocicl/ocicl

brabel 3y ago

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?

atgreen 3y ago
Man-in-the-middle attacks. But equally important, many secure environments won't allow outbound http connections.
- akho 3y ago
  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.
  - isityouyesitsme 3y ago
    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?
    - akho 3y ago
      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 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.