Skip to content

Conversation

@echawk
Copy link

@echawk echawk commented Nov 15, 2025

This is an initial test of the solution proposed in:

#14

What is odd is that the md5sum checksum succeeds, yet the sha1sum fails.

This is an initial test of the solution proposed in:

rudolfochrist#14

What is odd is that the md5sum checksum succeeds, yet the sha1sum fails.
@rudolfochrist rudolfochrist self-assigned this Nov 25, 2025
@echawk
Copy link
Author

echawk commented Dec 5, 2025

@rudolfochrist I figured out what the issue was.

It turns out that ultralisp uses a different sha1 scheme than upstream quicklisp - I have some working code (although it does depend on bringing in babel-streams and ironclad, so I'm not sure if it should be merged in at the moment).

The ultralisp implementation of sha1 is here.

I already have a check present to see what distribution the archive is from, and will call the correct hash function depending on if it is from quicklisp/ultralisp.

Perhaps these could be extracted out to their own systems? Then users could just :load-system :ql-https/quicklisp
and :load-system :ql-https/ultralisp, etc. to get the full sha checking - and just default to using curl over https otherwise.

@echawk
Copy link
Author

echawk commented Dec 8, 2025

@rudolfochrist Right now I'm experimenting to see if I can get this to work the way that I would like it to - if you have any suggestions though I am open to them.

@rudolfochrist
Copy link
Owner

Hi @echawk,

thank you for looking into this.

I just skimmed the Ultralisp code and I'm not a cryptography specialist, but Ultralisp using a different sha1 scheme sounds not right. This means that quicklisp (without ql-https) can't verify content hashes for Ultralisp releases as well. This should be fixed, but not by ql-https.

@svetlyak40wt Perhaps you can give some input here. Thanks.

Secondly, I'm feeling a little uneasy having special case handling for different dists. Sure, Ultralisp is public and prominent, but I don't want to have special handling for every arbitrary dist. We should prioritise that every dist works with vanilla quicklisp.

Thirdly, I would like to avoid third party dependencies with ql-https. Especially ironclad. Full ironclad takes a while to compile and we pollute every image with ironclad that loads dependencies with quicklisp. I would not like to do that.

Perhaps you find a way to bring this feature in while addressing the points above. Thank you 👍

:version (:read-file-line "version")
:depends-on ((:require "uiop") (:feature :sbcl :sb-md5))
:depends-on ((:require "uiop")
#+ql-https/ultralisp-check-sha1 (:require "ironclad")
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Read-time conditionals in system definitions is actually discouraged.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be ameliorated if openssl can be used to compute the sha1 digest - I'm not sure how to emulate the behavior of babel streams that we use for the computation of ultralisp's checksum

:depends-on ((:require "uiop") (:feature :sbcl :sb-md5))
:depends-on ((:require "uiop")
#+ql-https/ultralisp-check-sha1 (:require "ironclad")
#+ql-https/ultralisp-check-sha1 (:require "babel-streams")
Copy link
Owner

@rudolfochrist rudolfochrist Dec 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the (:require ...) clause is unnecessary. ASDF finds "babel-streams" if it is installed to a place where ASDF looks for systems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants