![]() ![]() ![]() It's not top-noch security as they have to include their CA into their server and protect it, but it's way better than a hard-coded Kiwix CA or certificate in the repo. The use case I have in mind is BSF, creating a root CA for its deployments so their clients are not prompted with warnings. It will allow trsuting that root certificate to client devices yet use the generated mechanism. That tool should be able to create a Certificate from a given Common Name but should also be capable of guessing IPs and hostnames of the machine and use that in SAN or Common Name.Īnother use case would be for that tool to take a -root-cert path and sign generated certificates with that root CA. Ideally, that would be a separate tool that's used to generate the certificate passed to kiwix-serve, but I'm not sure how practical that is. In a second step, we'd want to help people without a certificate. This would be used by anyone with a real certificate or want to use a trusted certificate. So we need an option to pass a certificate (path) to kiwix-serve. I actually think it would help ensure we don't take too many shortcuts. We could even release a first version with just HTTPS. OK, I think we need to separate the certificate stuff from the HTTPS one. This is example configuration for nginx : kiwix-serve is far from being able to handle that.īut anyway, even if we go this way, we don't need https, this is not needed on localhost for service worker. It will turn our applications as "specialized browser" (aka webapp). This is a big change in how we do things. This is necessary for example to get the HTTP daemon embedded within kiwix-desktop/android able to service ZIMit ZIM files. And, as certificate expires, we would have expiring binaries. It would means that we distribute the certificate (and its private part). ![]() We really don't want to hardcode the certificate in the source-code. Of course we would have to hardcode the certificate in the source-code. We are not security people and I don't want to become one. We will always need some kind of configuration from the user.Īdding https on top of a local http service is pretty easy with nginx, httpd or caddy.ĭistributor should use them to correctly setup a production server. We should not take care about the deployment of our software. It appears in above library.xml only because I subsequently tried out an old copy of 2.0 beta 5 to see if the crash was a new issue or not.I'm not sure we should handle this (in fact, I don't want to). There is one thing that puzzles me: the crash in 2.0.4 occurred before I ever tried to open wikipedia_en_all_maxi_2020-06.zim in Kiwix Desktop (and Kiwix JS does not use library.xml). Maybe more robust code is needed to catch exceptions and skip the operation in course? Nevertheless, it's clearly undesirable for Kiwix Desktop to crash when encountering a buggy ZIM file, especially if it is not actually trying to load that file. On doing a full file recheck with qBitTorrent, it identified the corrupt sector and re-downloaded it. The file was readable (by both Kiwix JS and Kiwix Desktop) but it caused a crash in Kiwix Desktop (not Kiwix JS) whenever I tried to search for a title. The new full English Wikipedia ( wikipedia_en_all_maxi_2020-06.zim), which I had downloaded with a BitTorrent client, had a minor corruption issue in one of the sectors downloaded, affecting titles from Dad to Deir in the Title Pointer List (or maybe URL pointer list). I think I can now narrow this bug down to a crash while reading a corrupt ZIM archive, as you suggested. ![]()
0 Comments
Leave a Reply. |