search

lwthiker / curl-impersonate

curl-impersonate: A special build of curl that can impersonate Chrome & Firefox
MIT License
3.46k stars 229 forks source link

linux/arm64 docker images missing on Docker Hub #92

Open wrobelda opened 1 year ago

wrobelda commented 1 year ago

Is there any reason why you're not publishing linux/arm64 images to Docker Hub? I was able to successfully build all the ones I needed locally, so I assume they work just fine?

lwthiker commented 1 year ago

Yeah it's built just fine, but since building Docker images for arm64 on an x86 machine requires emulation, the build is extremely slow. On my local machine it took upward of 1.5 hours, which means it will be even slower on the GitHub action runners. That's why I haven't added it yet, as it will slow down the CI significantly.

Maybe we should use an external CI provider for that? I'm not sure yet.

wrobelda commented 1 year ago

Frnakly speaking, I have no idea, but one thing to consider would be splitting the process into cross-compiling the code and using emulation for the image building stage only? See https://www.docker.com/blog/multi-platform-docker-builds ("Cross-Compilation" section).

wrobelda commented 1 year ago

One more thing comes to mind: why do you rebuild nss, brotli, nghttp2, etc when building a docker file? Wouldn't apt source curl, apt install build-essentials curl, patch, debuild approach work better? This way you could keep the compilation to the minimum and end up with a clean image?

And, with that in mind, have you considered setting up a deb repository? I realize this is extra work, but it vastly simplifies the usage from the user's perspective :)

lwthiker commented 1 year ago

One more thing comes to mind: why do you rebuild nss, brotli, nghttp2, etc when building a docker file

nss is always built statically into curl-impersonate to ensure that the TLS signature is the expected one. If the binary is used on another system with a different nss version, I can't ensure the TLS signature will be the same. It used to be my thinking with respect to brotli & nghttp2 as well, though I now less believe there is a room for errors if a different versions of these libraries is used. So I might in the future just link them dynamically as you suggested. Their build times are insignificant (as compared to nss for example) so I didn't put the time in to change it yet.

And, with that in mind, have you considered setting up a deb repository? I realize this is extra work, but it vastly simplifies the usage from the user's perspective :)

Yes, I hope to have rpm & deb set up in the future. As always, any help with that regard will be highly appreciated.