Re: comp.lang.prolog Frequently Asked Questions

The problem is the analogue of
the pager explosion:
 > package manager directly talks to https
Thats correct, I get:
 > ?- setting(prolog_pack:server, ServerBase).
 > ServerBase = 'https://www.swi-prolog.org/pack/'.
The pack server could nevertheless act as a
multiplier of malicious software. For example
if we look at supply chain attacks, then the
weakest link determines the overall security.
How do you initially compute the hash? @kuniaki.mukai
page doesn’t have HTTP to HTTPS promotion, and
here he has published a HTTP url:
Package “pac”
1.9.8 526129e98f3910766eace5d63eaf7097739a7c5b 3 http://web.sfc.keio.ac.jp/~mukai/pac-1.9.8.tgz
https://www.swi-prolog.org/pack/list?p=pac
And the hash is listed side by side with a
HTTP URL, doesn’t make much sense to me,
since its not a HTTPS URL. A hacker can use
this as a gateway to distribute a tampered
.tar that automatically has a tampered hash.
And its not a blockchain and/or distributed,
you compute the hash from the downloaded .tar
alone at client side, and what is computed at
client side is identical to the server side,
so there is no additional security. Or maybe
there is additional security? How is the pack
upload realized on the packager side? I don’t know…
Mild Shock schrieb:

Since spoofing GIT content is so easy and
non-sandboxed Prolog code is a rather sensitive
thing, I guess this is why bother with HTTPS
 and a HSTS (HTTP Strict Transport Security)
policy could be important. SWI-Prolog packs are
non-sandboxed, unlike SWISH notebooks, right?
 Here is what ChatGPT says:
 An HTTP to HTTPS redirect vulnerability occurs
when an insecure HTTP connection is used to
redirect users to a secure HTTPS connection,
but the initial HTTP request is not adequately
protected. Here’s how this vulnerability might be exploited:
 - Man-in-the-Middle Attack (MitM): Since HTTP is
unencrypted, an attacker intercepting the
initial HTTP request could manipulate the
redirection process before the user reaches
the secure HTTPS site. This could involve:
 * Redirecting the user to a malicious site that
looks identical to the intended destination.
* Modifying the content in transit, such as
injecting malicious scripts.
 - Downgrade Attacks: Attackers could attempt to
keep users on an HTTP connection instead of
redirecting them to HTTPS, leaving communication
vulnerable to eavesdropping or tampering.
 The severity of an HTTP to HTTPS redirect
vulnerability can vary depending on the
context, but it is generally considered
moderate to high, depending on the following factors:
 - Moderate: For non-sensitive sites where the
main risk is traffic manipulation (e.g., content
modification or ads injection) without
significant consequences.
 - High: For sites handling sensitive user data
(e.g., financial services, medical information),
especially when users are likely to connect
over insecure networks like public Wi-Fi.