mitm6 VS quicklisp-client

I've been learning some common lisp, reading through Practical Common Lisp, and it's really neat. People say the good ideas of lisp got adapted in other languages and sure that's true of garbage collection, lambda's and some others, but I'm seeing plenty incredible stuff I haven't seen elsewhere, the condition system that among other things lets you fix and resume your program on exception, real interactive development, flexible object system, macros way more understandable than in other languages with AST macros as in lisp the AST is simple, an expressive dynamic language at high level of ruby and python while being an order of magnitude faster performance. Quicklisp also is really neat, how many other package managers can load new dependencies without restarting your application? And I was learning it with idea that it's not just of historical or hobby interest but legitimately a good choice I can use for new programming projects today for many tasks, but I just learned something that makes it impossible for me to consider, which is complete lack of security of quicklisp. You go to the website and see sha256 hash and PGP signature for quicklisp download, awesome it seems at the security standard you expect for a package manager. But then the actual quicklisp client does all downloads over http with no verification. What this means in practical terms is basically if you use quicklisp, anyone on your local network can easily hack your computer, by MITM (man-in-the-middle) the traffic and serving you backdoored software when you install packages from quicklisp. mitm6 will MITM windows machines on normal networks, bettercap can MITM linux and os x on most networks. Aside from attackers on your local network there's plenty other scenarios, you can go near office of CL using company and set up a open WIFI access point with same name as company wifi and hack their developers, using quicklisp over something like Tor is extremely dangerous at present as it would let the exit node backdoor the packages you download, and then in less likely but still should be protected against scenarios is just if quicklisp.org or any router between you and it is compromised, you can be hacked.

I'm seeing Responder work less and less often as more time goes by. There was a windows patch in 2016 that should result in Windows systems no longer trying to authenticate to hostnames resolved over LLMNR or NBT-NS. If you don't get any hashes with Responder, next try using mitm6 (https://github.com/dirkjanm/mitm6) or Pretender (https://github.com/RedTeamPentesting/pretender). If fully patched and properly configured, Windows hosts will only send credentials to hosts discovered via DNS, and since DHCPv6 is usually left unconfigured, you can poison DHCPv6 broadcasts to announce yourself as the preferred DNS server and you can get hashes or relay.

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.

The latest comment I see about this here from Oct. 2022 says they're working on it. There's also comment by the developer in 2016 saying want to improve the security soon, so it doesn't really seem this will actually happen soon. I realise making signature verification work cross platform in pure lisp without external dependencies isn't easy but from latest comment it seems they have that working, in a branch written 4 years ago? The simplest no-code solution is just since quicklisp is published every month or so, on each new update publish a file with sha256 hash of every package contained in quicklisp signed with same developer's pgp key they are already using to sign download of the initial quicklisp.lisp, yes then users if they care about security would have to manually download the file and verify signature every month or so but it's at least some solution that can be done now.

> That's what regular devs do, they don't even bother writing articles or commenting on HN :-)

I'll take the bait, and roll up several of my comments into one.

First, the support contract costs from the commercial vendors can make sense. It's one of the most expensive parts of software. We joke about fixing relatives' printers, but its not false. Support costs introduce a counter-balance.

Second, a message to everyone looking into or using QuickLisp, it uses http instead of https: https://github.com/quicklisp/quicklisp-client/issues/167

You can patch your version to fix this. I'd also recommend adding firewall rules to deny in case your patches roll back. And any other mitigation. Or stricter policies, such as not using it, if it makes sense for your organization.

And the AI bots? I hope there aren't people herding them who don't want to, that's how you get unloving brats and a crappy world.

I found this github issue about it, open since 2018: https://github.com/quicklisp/quicklisp-client/issues/167

I agree 100% about needing to test and audit for security. But based on the information I've seen and public activity in repos, I assumed Xach was going for home-grown CL implementation. https://github.com/quicklisp/quicklisp-client/blob/pgp/quicklisp/openpgp.lisp