SQLite Forum


9 forum posts by user sodface

16:15 Reply: Packaging althttpd (artifact: bb8e226432 user: sodface)

Just wanted to follow up on this. I packaged this for my own use originally but also just got it merged into Alpine's testing repo:


14:58 Reply: althttpd and Cloudflare source IPs (artifact: 4667f5da95 user: sodface)

I'm now thinking that maybe the imposter domain used the same hosting provider I do, was using cloudflare as a reverse proxy and then abandoned the domain / stopped paying the provider and I've received their old IP address. If they never updated their cloudflare account then I guess they could still be pointing at the server ip now assigned to me. I've submitted a ticket with cloudflare.

13:42 Post: althttpd and Cloudflare source IPs (artifact: 11308d3917 user: sodface)

I use althttpd and had my public site configured to serve content from the default.website directory. I noticed on a google search that my content was showing up in search results under a different domain name that I do not own. Browsing that domain was exactly like browsing my real domain. Updates I made to my site were instantly visible in the imposter domain.

I changed from default.website to the specific domain format and now browsing to the imposter domain results in a 404 being returned, as expected. So that was a quick mitigation.

In reviewing the server logs I determined that all the source IPs belonged to Cloudflare. Also, looking at the html source from the returned 404 page, there's a script tag in the head that references "CloudflareApps".

If I'm interpreting it correctly, it seems whoever owns the imposter domain has it configured to resolve to a Cloudflare proxy and is then somehow returning my domain content. It's not just a redirect so far as I can tell by looking at the developer's tools in Firefox.

Beyond changing from default.website, do you have any suggestions on additional action? Seems like I could drop all Cloudflare IP ranges at my firewall without blocking legitimate traffic?

02:34 Reply: Packaging althttpd (artifact: 39c807f63e user: sodface)

When specifying a filename, the filename without the .zip suffix is contained in the resulting zip file. The md5sums for the first three above are different because of the difference in the folder names contained in the zips. The actual althttpd.c source code files are identical however.

This also explains why the last three with the same name have matching checksums.

I believe the problem with all the examples on this page, including the one in my first post, is that we should be using r= instead of ci=

With ci= I think it is ignored and you just always get the latest trunk check-in.

Testing with r= gives me the expected results.

Sorry for causing confusion.

19:43 Reply: Packaging althttpd (artifact: e0e06e1f18 user: sodface)

Sorry for the multiple posts. I edited the APKBUILD to set pkgver to the full date tag "YYYYMMDDHHMM" and used ci=$pkgver in the source url. I'm setting the download source filename to $pkgname-$pkgver.zip I ran abuild checksum twice with two different date tags in pkgver and abuild computed the same checksum

sha512sums="-snip-06a13d  althttpd-202005092232.zip
sha512sums="-snip-06a13d  althttpd-202004281307.zip

I'm probably doing something obviously wrong here but I'm not seeing it.

19:22 Reply: Packaging althttpd (artifact: 730bdff21d user: sodface)

Confusingly, when downloading with firefox:


md5sums are all different as expected.

$ md5sum althttpd-*
fcdd2ddd3f6e546f5dea665e51dbc12f  althttpd-1.zip
993e1b78581a7d9a1f17dcbe21cd25c0  althttpd-2.zip
bb7d72e9a01a3745163f416823f42d2a  althttpd-3.zip

But if I use the same filename and let firefox rename, the md5sums are the same:


$ md5sum althttpd*
6a09f995294fc12587a94ee38a483f92  althttpd(1).zip
6a09f995294fc12587a94ee38a483f92  althttpd(2).zip
6a09f995294fc12587a94ee38a483f92  althttpd.zip
18:46 Reply: Packaging althttpd (artifact: 8cfe731cb5 user: sodface)

Specifying the filename as part of the url doesn't appear to work with Alpine's build tools. Using a url like:


the abuild tool fetches the file and the local filename is althttpd.c instead of althttpd.zip, though the .c file is actually zipped. I'll probably go back to using the Alpine syntax for renaming in the form:


The first form is named correctly when downloading with firefox but abuild is probably using wget or something on the backend and it's not producing the intended filename.

14:18 Reply: Packaging althttpd (artifact: b98d43ac38 user: sodface)

I thought about using the trunk link so I didn't have to update it but the abuild package system appends source file checksums in the package build file so a specific package version would fail to (re)build if there was a new check-in.

For my own use this might even be a good thing but I think official packages have to be repeatable.

The packaging system provides a facility for renaming the downloaded source file which I was using but thanks for the tip on specifying a name, I will switch to that.

It occurs to me I might need to re-think the date style version number, not sure how the package manager determines how one package is newer than another. Would it consider 04.01.2019 to be newer than 01.04.2020 for example? I might need to put the year first.

13:50 Post: Packaging althttpd (artifact: 9d6bf54118 user: sodface)

I'm packaging althttpd for Alpine Linux and hosting the package file in a personal repo (said repo is being served by althttpd also).

I'm using a date format in the package build as a version number:


A link to the src:


and this link for the overall project url:


Just wondering if this looks about right? The package builds fine and creates an open-rc sub-package to integrate with the service management system.

It took me a few tries to come up with the src url but I believe the form above will always get the same source that corresponds with the version date as listed in the pkgver variable? To update the build I'm changing the version date and the ci= portion of the src url to the new check-in string.

I'm also applying a patch to allow plus signs in filenames as many of the files in the repo have them, eg. c++