On 10/21/24 11:41, rolfm@dds.nl wrote:
hi,
Windows 11, Firefox
today, trying to download a DEK-file from https://deken.puredata.info/ https://deken.puredata.info/
i get this pop-up message
this did not happen the last time i visited Deken.
then you browser was updated in the meantime :-)
the problem is , that these days browser do not like downloading stuff over http:// any more - *especially* when the http:// download is referred to from a https:// page. this somewhat makes sense, as the security is downgraded from a secure-protocol to an insecure one, and the rowser tries to warn you that now all kind of things could go wrong (man-in-the-middle attacks and what now), while you might (wrongly) believe, that everything is secured via https://.
(in your case: you access httpS://deken.puredata.info/, but it then links to a file on http://puredata.info/ (without the 's').
the reason, why deken uses the insecure http:// links is, that most Pd's out there don't know how to speak https://. TclTk itself does not come with https:// support, only with rudimentary (but good enough for our use-case) http:// support. As a user you can manually install the tcl-tls extension, and Pd will start to speak https://, but while this is easy on linux (with a system-installed TclTk), it's much more complicated on macOS and Windows. I just checked, and our deken server sees about 50 times more access via the http:// than via https://
because of these, the actual links to the DEK-packages (as stored in the deken database) use the http:// protocol.
one possible solution would be to check whether deken.puredata.info is accessed via https://, and then rewrite the package URLs to use https:// as well. i didn't implement this, as I did not want to special case the puredata.info server (which happens to make all content available via both https:// and http:// (the latter for precisely the reason to allow Pd to download the files). of course, puredata.info is currently the *only* server that deken.puredata.info speaks to, so my quest for generalization might be a bit over-the-top.
maybe, i'll implement something (there's already https://git.iem.at/zmoelnig/deken-server/-/issues/7), but i have no ETA.
in any case: the quick workaround for now, is to accept the security risk (and eventually verify the packages via the SHA256 sum and their gpg-signature - if there is one).
*or* just go insecure all the way and use http://deken.puredata.info/ (but this might not work, if you ever accessed https://deken.puredata.info/, as the browser remembers that it should access this page via https://)
gadmfsr IOhannes