Menu
▾
▴
gnuplot-beta
|
From: Ethan A M. <me...@uw...> - 2025-09-09 17:44:40
|
As of this morning I can't seem to reach gnuplot.info via either http or https. The similar problems reported here last year and earlier this year did not seem to affect my connection here, so the current issue is either something altogether different or else affects a larger fraction of the CloudFlare network coverage. Access to the underlying web site on SourceForge is still OK. It's just the redirection though gnuplot.info that is broken. - Ethan |
|
From: Philipp K. J. <ja...@ie...> - 2025-09-09 18:23:00
|
On Tue, 9 Sep 2025 10:10:35 -0700 Ethan A Merritt <me...@uw...> wrote: > As of this morning I can't seem to reach gnuplot.info via either http > or https. The similar problems reported here last year and earlier > this year did not seem to affect my connection here, so the current > issue is either something altogether different or else affects a > larger fraction of the CloudFlare network coverage. > > Access to the underlying web site on SourceForge is still OK. It's > just the redirection though gnuplot.info that is broken. Actually, I can't confirm that. I can reach http://www.gnuplot.info but httpS gives me the error message I posted yesterday. Is it possible that I have a local DNS cache that makes this possible? (Wild, clueless speculation...) I am located in the East (PA). Regional problem? > > - Ethan |
|
From: Folkert v. H. <fo...@va...> - 2025-09-09 19:46:17
|
>> As of this morning I can't seem to reach gnuplot.info via either http >> or https. The similar problems reported here last year and earlier >> this year did not seem to affect my connection here, so the current >> issue is either something altogether different or else affects a >> larger fraction of the CloudFlare network coverage. >> >> Access to the underlying web site on SourceForge is still OK. It's >> just the redirection though gnuplot.info that is broken. > > Actually, I can't confirm that. I can reach > http://www.gnuplot.info > but httpS gives me the error message I posted > yesterday. > > Is it possible that I have a local DNS cache > that makes this possible? (Wild, clueless > speculation...) > > I am located in the East (PA). Regional problem? Doubt it. Here in the Netherlands (Europe) the problem is the same: https://imgpaste.nurd.space/pics/bd60183c8b9f65e72283b63d2f8c95bdb5b33b0835a40305234b9d463a70d83e.png -- www.vanheusden.com |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2025-09-09 21:23:12
|
Am 09.09.2025 um 19:10 schrieb Ethan A Merritt: > As of this morning I can't seem to reach gnuplot.info <http:// > gnuplot.info> via either http or https. We have to be sticklers to detail here to avoid extra confusion. Philipp had problems accessing www.gnuplot.info via https. Ethan can't link to gnuplot.info (note: no leading www.). So I went ahead and tracert'd to both names. I get an IPv4 address for www.gnuplot.info (204.68.111.101), whereas gnuplot.info traces to an IPv6 address ([2606:4700:4400::ac40:9691]). http://www.gnuplot.info via just works. https://www.gnuplot.info barfs because the site certificate does not report itself as matching the site name. That kind-a figures, as the certificate is from SourceForge, which does host that actual site, but not the *.gnuplot.info redirects. https://gnuplot.info fails with a _different_ problem: neither FireFox nor Edge could agree with the server on any cypher algorithm both sides allow/support. http://gnuplot.info also fails, with a "DNS resolution error 1001" reported by Cloudflare. Which is strange, as tracert did get an IP, i.e. DNS actually works. |
|
From: Ethan A M. <me...@uw...> - 2025-09-09 23:20:08
|
On Tuesday, 9 September 2025 14:22:58 PDT Hans-Bernhard Bröker wrote:
> Ethan can't link to gnuplot.info (note: no leading www.).
Good point. I typed the address into the browser directly because Phillipp's
reported error message was
"Firefox does not trust this site because it uses a certificate that is not
valid for gnuplot.info"
> [...] also fails, with a
> "DNS resolution error 1001" reported by Cloudflare.
> Which is strange, as tracert did get an IP, i.e. DNS actually works.
Yes. That's the one I'm seeing. It's an internal error message from Cloudflare
that I get when I request either http://gnuplot.info or https://gnuplot.info
It does work if I request http://www.gnuplot.info (Chrome or Firefox browsers).
The hyperlink references in the pdf version of the user manual use the
www.gnuplot.info form. But the html versions of the manual use
the gnuplot.info form [no www] everywhere.
That much I can fix.
I will modify the gnuplot.doc inline html tables and the code in
doc2web.c to always generate output with the www prefix in the URL.
However it is probably a common "mistake" for users to omit the www prefix in web
queries since that is no longer as near-universal as it once was. For that matter
Chrome actively hides the "www." prefix when it shows the current site in the bar
at the top, so a cut-and-paste may fail to capture the full, working, address.
Ethan
|
|
From: Philipp K. J. <ja...@ie...> - 2025-09-10 12:53:53
|
On Tue, 09 Sep 2025 16:19:58 -0700 Ethan A Merritt <me...@uw...> wrote: > On Tuesday, 9 September 2025 14:22:58 PDT Hans-Bernhard Bröker wrote: > I don't want to be a stickler, but I don't think changing the docs from "gnuplot.info" to "www.gnuplot.info" is really the right way to think about it. The domain/server should be configured to accept both versions and serve the appropriate content. That's pretty standard issue, in my experience. Best, Ph. > > > Ethan can't link to gnuplot.info (note: no leading www.). > > Good point. I typed the address into the browser directly because > Phillipp's reported error message was > "Firefox does not trust this site because it uses a certificate > that is not valid for gnuplot.info" > > > [...] also fails, with a > > "DNS resolution error 1001" reported by Cloudflare. > > Which is strange, as tracert did get an IP, i.e. DNS actually > > works. > > Yes. That's the one I'm seeing. It's an internal error message from > Cloudflare that I get when I request either http://gnuplot.info or > https://gnuplot.info > > It does work if I request http://www.gnuplot.info (Chrome or > Firefox browsers). > > The hyperlink references in the pdf version of the user manual use > the www.gnuplot.info form. But the html versions of the manual use > the gnuplot.info form [no www] everywhere. > > That much I can fix. > I will modify the gnuplot.doc inline html tables and the code in > doc2web.c to always generate output with the www prefix in the URL. > > However it is probably a common "mistake" for users to omit the www > prefix in web queries since that is no longer as near-universal as it > once was. For that matter Chrome actively hides the "www." prefix > when it shows the current site in the bar at the top, so a > cut-and-paste may fail to capture the full, working, address. > > Ethan > > > > > > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > Membership management via: > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta |
|
From: Ethan A M. <me...@uw...> - 2025-09-10 17:51:33
|
On Wed, Sep 10, 2025 at 5:53 AM Philipp K. Janert via gnuplot-beta < gnu...@li...> wrote: > On Tue, 09 Sep 2025 16:19:58 -0700 > Ethan A Merritt <me...@uw...> wrote: > > > I don't want to be a stickler, but I don't > think changing the docs from "gnuplot.info" > to "www.gnuplot.info" is really the right > way to think about it. [shrug] That's the only part of it I can do myself, and it takes effect immediately. The on-line docs now work again (as seen from here), whereas access was failing yesterday. I hope someone else can arrange a more global long-term fix or at least identify what that fix would be. > The domain/server should be configured to > accept both versions and serve the appropriate > content. That's pretty standard issue, in my > experience. To the limited extent that I understand the error messages that I am seeing, it is not a matter of appropriate content on the server. The query is never getting to the server because some intermediate service provider is failing to deliver it. If I am misunderstanding and there is some configuration thing I can change on the SourceForge end, please let me know. Ethan Best, > > Ph. > > > On Tuesday, 9 September 2025 14:22:58 PDT Hans-Bernhard Bröker wrote: > > > > > Ethan can't link to gnuplot.info (note: no leading www.). > > > > Good point. I typed the address into the browser directly because > > Phillipp's reported error message was > > "Firefox does not trust this site because it uses a certificate > > that is not valid for gnuplot.info" > > > > > [...] also fails, with a > > > "DNS resolution error 1001" reported by Cloudflare. > > > Which is strange, as tracert did get an IP, i.e. DNS actually > > > works. > > > > Yes. That's the one I'm seeing. It's an internal error message from > > Cloudflare that I get when I request either > https://urldefense.com/v3/__http://gnuplot.info__;!!K-Hz7m0Vt54!hKklbxAh2wg2JWTINjAGHDtkHTSmzmPsg4w5G1Zu-N3BPWS_Fszt9uVqK6s9gOHUge9KIxOjuZdyCw6GT_4X1lxPgQ2mvA$ > or > > > https://urldefense.com/v3/__https://gnuplot.info__;!!K-Hz7m0Vt54!hKklbxAh2wg2JWTINjAGHDtkHTSmzmPsg4w5G1Zu-N3BPWS_Fszt9uVqK6s9gOHUge9KIxOjuZdyCw6GT_4X1lxK_p5wIQ$ > > > > It does work if I request > https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!hKklbxAh2wg2JWTINjAGHDtkHTSmzmPsg4w5G1Zu-N3BPWS_Fszt9uVqK6s9gOHUge9KIxOjuZdyCw6GT_4X1lxJY2e2hg$ > (Chrome or > > Firefox browsers). > > > > The hyperlink references in the pdf version of the user manual use > > the > https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!hKklbxAh2wg2JWTINjAGHDtkHTSmzmPsg4w5G1Zu-N3BPWS_Fszt9uVqK6s9gOHUge9KIxOjuZdyCw6GT_4X1lxJY2e2hg$ > form. But the html versions of the manual use > > the gnuplot.info form [no www] everywhere. > > > > That much I can fix. > > I will modify the gnuplot.doc inline html tables and the code in > > doc2web.c to always generate output with the www prefix in the URL. > > > > However it is probably a common "mistake" for users to omit the www > > prefix in web queries since that is no longer as near-universal as it > > once was. For that matter Chrome actively hides the "www." prefix > > when it shows the current site in the bar at the top, so a > > cut-and-paste may fail to capture the full, working, address. > > > > Ethan > > > > > > > > > > > > _______________________________________________ > > gnuplot-beta mailing list > > gnu...@li... > > Membership management via: > > > https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!hKklbxAh2wg2JWTINjAGHDtkHTSmzmPsg4w5G1Zu-N3BPWS_Fszt9uVqK6s9gOHUge9KIxOjuZdyCw6GT_4X1lypuFKcMA$ > > > > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > Membership management via: > https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!hKklbxAh2wg2JWTINjAGHDtkHTSmzmPsg4w5G1Zu-N3BPWS_Fszt9uVqK6s9gOHUge9KIxOjuZdyCw6GT_4X1lypuFKcMA$ > -- Ethan A Merritt Department of Biochemistry University of Washington, Seattle |
|
From: Juhász P. <pet...@gm...> - 2025-09-10 18:35:10
|
On Wed, 2025-09-10 at 10:51 -0700, Ethan A Merritt wrote: > To the limited extent that I understand the error messages that I am > seeing, > it is not a matter of appropriate content on the server. The query > is never > getting to the server because some intermediate service provider is > failing to > deliver it. If I am misunderstanding and there is some configuration > thing I > can change on the SourceForge end, please let me know. > Hi, you've mentioned that the actual content is hosted on/by SourceForge. Under what kind of formal or informal arrangement or contract does this happen? Was any payment involved? The error message means that the certificate required to serve the site over HTTPS is not valid for the domain name gnuplot.info (nor www.gnuplot.info). If you look at the certificate (offered by Firefox next to the error message), you can see that it was issued by Let's Encrypt to secureprojects.sourceforge.net, and it is valid for a large selection of other domain names, presumably all projects hosted by SF. The certificate is valid between Tue, 29 Jul 2025 02:33:38 GMT and Mon, 27 Oct 2025 02:33:37 GMT. So the person who is responsible for renewing this certificate at SF either made a mistake by not including gnuplot.info (and in this case a gentle reminder may fix the issue in October at the very latest, possibly earlier), or deliberately removed gnuplot.info from the list of domains, because the afore-hypothesized contract has expired (in which case the gentle reminder may have to include money). As to whom that gentle reminder should be sent, I have no idea. best regards, Peter Juhasz |
|
From: Ethan A M. <me...@uw...> - 2025-09-10 22:45:25
|
On Wed, Sep 10, 2025 at 11:35 AM Juhász Péter <pet...@gm...> wrote: > On Wed, 2025-09-10 at 10: 51 -0700, Ethan A Merritt wrote: To the limited > extent that I understand the error messages that I am seeing, it is not a > matter of appropriate content on the server. The query is never getting to > the server because > ZjQcmQRYFpfptBannerStart > On Wed, 2025-09-10 at 10:51 -0700, Ethan A Merritt wrote: > > To the limited extent that I understand the error messages that I am > seeing, > it is not a matter of appropriate content on the server. The query is > never > getting to the server because some intermediate service provider is > failing to > deliver it. If I am misunderstanding and there is some configuration > thing I > can change on the SourceForge end, please let me know. > > > Hi, > > you've mentioned that the actual content is hosted on/by SourceForge. > > Under what kind of formal or informal arrangement or contract does this > happen? Was any payment involved > No payment or formal contract with SourceForge that I know of. The error message means that the certificate required to serve the site > over HTTPS is not valid for the domain name gnuplot.info (nor > www.gnuplot.info > <https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!hZAtTCSEA3UZsTRDYd1Rlg-J8_Oq7DJZg-cJMaMoMBMcyZx3lwvCVqHE401p-ZikRUWZruc71FaDNhZkYYE3tw4$>). > If you look at the certificate (offered by Firefox next to the error > message), you can see that it was issued by Let's Encrypt to > secureprojects.sourceforge.net, and it is valid for a large selection of > other domain names, presumably all projects hosted by SF. > Thank you for your insights. I think you are addressing a different issue - whether the connection protocol is https or http. It is not surprising that a certificate issued to SourceForge would not mention gnuplot.info by name because that name is not connected to SourceForge except in that (as I understand it) it currently redirects queries to the actual gnuplot site gnuplot.sourceforge.net. The current problem seems to be that the redirection itself fails in some cases, or fails to pass through sufficient information (or credentials or something - I really really don't understand this stuff). If you are seeing an error message that refers to a SourceForge certificate then I think in your case the redirection must have succeeded. You still see the site, correct? It's just that connection is falling back to http rather that https. I was getting an error from some intermediary network entity (Cloudflare) that reports "DNS resolution error 1001". As Hans-Bernhard noted, that's rather odd because DNS does seem to work correctly when tested by command line tools. For completeness I should mention that the issue of connection via IPv6 as opposed to IPv4 was raised earlier, and might be relevant, but that goes way beyond my level of understanding. Ethan > So the person who is responsible for renewing this certificate at SF > either made a mistake by not including gnuplot.info (and in this case a > gentle reminder may fix the issue in October at the very latest, possibly > earlier), or deliberately removed gnuplot.info from the list of domains, > because the afore-hypothesized contract has expired (in which case the > gentle reminder may have to include money). > > As to whom that gentle reminder should be sent, I have no idea. > best regards, > > Peter Juhasz > |
|
From: Mojca M. G. <moj...@gm...> - 2025-09-11 00:18:38
|
On Thu, 11 Sept 2025, 00:45 Ethan A Merritt, <me...@uw...> wrote: > > > On Wed, Sep 10, 2025 at 11:35 AM Juhász Péter <pet...@gm...> > wrote: > >> The error message means that the certificate required to serve the site >> over HTTPS is not valid for the domain name gnuplot.info (nor >> www.gnuplot.info >> <https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!hZAtTCSEA3UZsTRDYd1Rlg-J8_Oq7DJZg-cJMaMoMBMcyZx3lwvCVqHE401p-ZikRUWZruc71FaDNhZkYYE3tw4$>). >> If you look at the certificate (offered by Firefox next to the error >> message), you can see that it was issued by Let's Encrypt to >> secureprojects.sourceforge.net, and it is valid for a large selection of >> other domain names, presumably all projects hosted by SF. >> > > Thank you for your insights. > > I think you are addressing a different issue - whether the connection > protocol is https or http. > Yes, this is not about DNS failure. I don't experience DNS failure, but see precisely the same errors/issues as Peter described. (Nowadays http should actually redirect to https. Modern browsers also refuse to show http pages.) It is not surprising that a certificate issued to SourceForge would not > mention gnuplot.info by name because that name is not connected to > SourceForge except in that (as I understand it) it currently redirects > queries to the actual gnuplot site gnuplot.sourceforge.net. > Except that it does matter for https. The hosting site needs to know that the certificate should also be for gnuplot.info and it needs to be explicit whether that is with or without www (or both). Either a separate certificate is needed for that, or the certificate used needs to be made aware that it needs to cover gnuplot.info. This really needs to be fixed on the hosting site, and usually the person in charge of the DNS is also needed in the process of making it work. Unless the administrators of gnuplot on SF have access to certificate settings (means you would also need to create and extend your own certificate), then SF support is really needed here to set it up. The current problem seems to be that the redirection itself fails in some > cases, or fails to pass through sufficient information > No. It's really a misconfigured site/certificate. > You still see the site, correct? Well ... yes and no, but the more correct answer is probably NO. By default you don't see the site because the web browser is protecting you from "the malicious site" until you approve an exception and security risk, but that is "an advanced use" (it is on purpose made difficult to do that). For completeness I should mention that the issue of connection via IPv6 as > opposed to IPv4 was raised earlier, and might be relevant, > It is possible that the site works correctly on IPv4 and fails with IPv6. My network right now doesn't support IPv6, so it's hard for me to check. It is unrelated to certificate issues, but it could hypothetically explain why DNS works for others and not for you if you have IPv6. (By correctly I mean resolving to the correct website. It still doesn't serve a compliant certificate.) Mojca > |
|
From: Jeremy N. - ml g. <jn....@wi...> - 2025-09-11 21:35:40
|
On 2025-09-11 01:18, Mojca Miklavec Groenhuis wrote: > (Nowadays http should actually redirect to https. Modern > browsers also refuse to show http pages.) While that is sensible for external websites, it needs to be configurable, so that one can login to admin interfaces on network routers etc. -- Jeremy Nicoll - my opinions are my own |
|
From: Ethan A M. <me...@uw...> - 2025-09-11 03:18:22
|
Thanks for the pointers. After poking around in the SourceForge admin pages I found a place to set up "virtual domains". Both gnuplot.info and www.gnuplot.info are already listed there. That same page states that https access can be enabled by request, so I placed a support request with the SourceForge site itself to enable https access via gnuplot.info and www.gnuplot.info. We'll see what happens. https://sourceforge.net/p/forge/site-support/27031/ Ethan On Wed, Sep 10, 2025 at 5:18 PM Mojca Miklavec Groenhuis < moj...@gm...> wrote: > On Thu, 11 Sept 2025, 00: 45 Ethan A Merritt, <merritt@ uw. edu> wrote: > On Wed, Sep 10, 2025 at 11: 35 AM Juhász Péter <peter. juhasz83@ gmail. > com> wrote: The error message means that the certificate required to serve > the site over HTTPS > ZjQcmQRYFpfptBannerStart > This Message Is From an Untrusted Sender > You have not previously corresponded with this sender. > See https://itconnect.uw.edu/email-tags for additional information. > Please contact the UW-IT Service Center, he...@uw... 206.221.5000, for > assistance. > > ZjQcmQRYFpfptBannerEnd > > > On Thu, 11 Sept 2025, 00:45 Ethan A Merritt, <me...@uw...> wrote: > >> >> >> On Wed, Sep 10, 2025 at 11:35 AM Juhász Péter <pet...@gm...> >> wrote: >> >>> The error message means that the certificate required to serve the site >>> over HTTPS is not valid for the domain name gnuplot.info >>> <https://urldefense.com/v3/__http://gnuplot.info__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODc4D2Pme$> >>> (nor www.gnuplot.info >>> <https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!hZAtTCSEA3UZsTRDYd1Rlg-J8_Oq7DJZg-cJMaMoMBMcyZx3lwvCVqHE401p-ZikRUWZruc71FaDNhZkYYE3tw4$>). >>> If you look at the certificate (offered by Firefox next to the error >>> message), you can see that it was issued by Let's Encrypt to >>> secureprojects.sourceforge.net >>> <https://urldefense.com/v3/__http://secureprojects.sourceforge.net__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODadFrph0$>, >>> and it is valid for a large selection of other domain names, presumably all >>> projects hosted by SF. >>> >> >> Thank you for your insights. >> >> I think you are addressing a different issue - whether the connection >> protocol is https or http. >> > > Yes, this is not about DNS failure. I don't experience DNS failure, but > see precisely the same errors/issues as Peter described. > > (Nowadays http should actually redirect to https. Modern browsers also > refuse to show http pages.) > > It is not surprising that a certificate issued to SourceForge would not >> mention gnuplot.info >> <https://urldefense.com/v3/__http://gnuplot.info__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODc4D2Pme$> >> by name because that name is not connected to SourceForge except in that >> (as I understand it) it currently redirects queries to the actual gnuplot >> site gnuplot.sourceforge.net >> <https://urldefense.com/v3/__http://gnuplot.sourceforge.net__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODckxZJT_$> >> . >> > > Except that it does matter for https. The hosting site needs to know that > the certificate should also be for gnuplot.info > <https://urldefense.com/v3/__http://gnuplot.info__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODc4D2Pme$> > and it needs to be explicit whether that is with or without www (or both). > Either a separate certificate is needed for that, or the certificate used > needs to be made aware that it needs to cover gnuplot.info > <https://urldefense.com/v3/__http://gnuplot.info__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODc4D2Pme$>. > This really needs to be fixed on the hosting site, and usually the person > in charge of the DNS is also needed in the process of making it work. > > Unless the administrators of gnuplot on SF have access to certificate > settings (means you would also need to create and extend your own > certificate), then SF support is really needed here to set it up. > > The current problem seems to be that the redirection itself fails in some >> cases, or fails to pass through sufficient information >> > > No. It's really a misconfigured site/certificate. > > > You still see the site, correct? > > Well ... yes and no, but the more correct answer is probably NO. By > default you don't see the site because the web browser is protecting you > from "the malicious site" until you approve an exception and security risk, > but that is "an advanced use" (it is on purpose made difficult to do that). > > For completeness I should mention that the issue of connection via IPv6 as >> opposed to IPv4 was raised earlier, and might be relevant, >> > > It is possible that the site works correctly on IPv4 and fails with IPv6. > My network right now doesn't support IPv6, so it's hard for me to check. It > is unrelated to certificate issues, but it could hypothetically explain why > DNS works for others and not for you if you have IPv6. (By correctly I mean > resolving to the correct website. It still doesn't serve a compliant > certificate.) > > Mojca > >> -- Ethan A Merritt Department of Biochemistry University of Washington, Seattle |
|
From: Juhász P. <pet...@gm...> - 2025-09-11 17:08:41
|
The plot thickens. I wanted to check on crt.sh (a certificate search facility) what certs were issued for gnuplot.info in the past. To my surprise, I didn't find any. However, they list test.gnuplot.info (and www.test.gnuplot.info) for which a certificate was issued first on 2024-03-02 and renewed ever since. And indeed, test.gnuplot.info does work with https. I did not know that this domain exists. Should it? Peter On Wed, 2025-09-10 at 20:17 -0700, Ethan A Merritt wrote: > Thanks for the pointers. > > After poking around in the SourceForge admin pages I found a place to > set up "virtual domains". Both gnuplot.info and www.gnuplot.info are > already listed there. That same page states that https access can be > enabled by request, so I placed a support request with the > SourceForge site itself to enable https access via gnuplot.info and > www.gnuplot.info. We'll see what happens. > > https://sourceforge.net/p/forge/site-support/27031/ > > Ethan > > On Wed, Sep 10, 2025 at 5:18 PM Mojca Miklavec Groenhuis > <moj...@gm...> wrote: > > On Thu, 11 Sept 2025, 00: 45 Ethan A Merritt, <merritt@ uw. edu> > > wrote: On Wed, Sep 10, 2025 at 11: 35 AM Juhász Péter > > <peter. juhasz83@ gmail. com> wrote: The error message means that > > the certificate required to serve the site over HTTPS > > ZjQcmQRYFpfptBannerStart > > > > > > > > This Message Is From an Untrusted Sender > > > > You have not previously corresponded with this sender. > > > > See https://itconnect.uw.edu/email-tags for additional information. > > Please contact the UW-IT Service Center, he...@uw... 206.221.5000, > > for assistance. > > > > > > > > > > ZjQcmQRYFpfptBannerEnd > > > > > > On Thu, 11 Sept 2025, 00:45 Ethan A Merritt, <me...@uw...> > > wrote: > > > > > > > > > On Wed, Sep 10, 2025 at 11:35 AM Juhász Péter > > > <pet...@gm...> wrote: > > > > > > > > The error message means that the certificate required to serve > > > > the site over HTTPS is not valid for the domain name > > > > gnuplot.info [1] (nor www.gnuplot.info [2]). If you look at the > > > > certificate (offered by Firefox next to the error message), you > > > > can see that it was issued by Let's Encrypt to > > > > secureprojects.sourceforge.net [3], and it is valid for a large > > > > selection of other domain names, presumably all projects hosted > > > > by SF. > > > > > > > > > > > > > Thank you for your insights. > > > > > > I think you are addressing a different issue - whether the > > > connection protocol is https or http. > > > > Yes, this is not about DNS failure. I don't experience DNS failure, > > but see precisely the same errors/issues as Peter described. > > > > (Nowadays http should actually redirect to https. Modern browsers > > also refuse to show http pages.) > > > > > It is not surprising that a certificate issued to SourceForge > > > would not mention gnuplot.info [1] by name because that name is > > > not connected to SourceForge except in that (as I understand it) > > > it currently redirects queries to the actual gnuplot site > > > gnuplot.sourceforge.net [4]. > > > > Except that it does matter for https. The hosting site needs to > > know that the certificate should also be for gnuplot.info [1] and > > it needs to be explicit whether that is with or without www (or > > both). > > Either a separate certificate is needed for that, or the > > certificate used needs to be made aware that it needs to cover > > gnuplot.info [1]. This really needs to be fixed on the hosting > > site, and usually the person in charge of the DNS is also needed in > > the process of making it work. > > > > Unless the administrators of gnuplot on SF have access to > > certificate settings (means you would also need to create and > > extend your own certificate), then SF support is really needed here > > to set it up. > > > > > The current problem seems to be that the redirection itself fails > > > in some cases, or fails to pass through sufficient information > > > > No. It's really a misconfigured site/certificate. > > > > > You still see the site, correct? > > > > Well ... yes and no, but the more correct answer is probably NO. By > > default you don't see the site because the web browser is > > protecting you from "the malicious site" until you approve an > > exception and security risk, but that is "an advanced use" (it is > > on purpose made difficult to do that). > > > > > For completeness I should mention that the issue of connection > > > via IPv6 as opposed to IPv4 was raised earlier, and might be > > > relevant, > > > > It is possible that the site works correctly on IPv4 and fails with > > IPv6. My network right now doesn't support IPv6, so it's hard for > > me to check. It is unrelated to certificate issues, but it could > > hypothetically explain why DNS works for others and not for you if > > you have IPv6. (By correctly I mean resolving to the correct > > website. It still doesn't serve a compliant certificate.) > > > > Mojca > > > > > -- > Ethan A Merritt > Department of Biochemistry > University of Washington, Seattle > > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > Membership management via: > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta [1] gnuplot.info https://urldefense.com/v3/__http://gnuplot.info__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODc4D2Pme$ [2] www.gnuplot.info https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!hZAtTCSEA3UZsTRDYd1Rlg-J8_Oq7DJZg-cJMaMoMBMcyZx3lwvCVqHE401p-ZikRUWZruc71FaDNhZkYYE3tw4$ [3] secureprojects.sourceforge.net https://urldefense.com/v3/__http://secureprojects.sourceforge.net__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODadFrph0$ [4] gnuplot.sourceforge.net https://urldefense.com/v3/__http://gnuplot.sourceforge.net__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODckxZJT_$ |
|
From: Ethan A M. <me...@uw...> - 2025-09-11 18:12:21
|
On Thursday, 11 September 2025 10:08:31 PDT Juhász Péter wrote: > The plot thickens. > > I wanted to check on crt.sh (a certificate search facility) what certs > were issued for gnuplot.info in the past. To my surprise, I didn't find > any. However, they list test.gnuplot.info (and www.test.gnuplot.info) > for which a certificate was issued first on 2024-03-02 and renewed ever > since. And indeed, test.gnuplot.info does work with https. > > I did not know that this domain exists. Should it? > Peter I think Clark Gaylord may be the best, if not the only, person to answer this. (CC'ed on this reply). Clark said last month that the gnuplot.info domain was set up "on ten year pre payment with auto renew". I don't know whether that includes subdomains or not. Please excuse my ignorance. I don't even know what a "certificate" means in this context, or how it fits in with domain registration. Anyhow, sourceforge supprt has acknowledged the request I made to them to enable https for gnuplot.info so that may yet take care of it. If there is something else I should ask them for, please let me know. Ethan > On Wed, 2025-09-10 at 20:17 -0700, Ethan A Merritt wrote: > > Thanks for the pointers. > > > > After poking around in the SourceForge admin pages I found a place to > > set up "virtual domains". Both gnuplot.info and www.gnuplot.info are > > already listed there. That same page states that https access can be > > enabled by request, so I placed a support request with the > > SourceForge site itself to enable https access via gnuplot.info and > > www.gnuplot.info. We'll see what happens. > > > > Support tracker: > > https://sourceforge.net/p/forge/site-support/27031/ > > Ethan > > > > On Wed, Sep 10, 2025 at 5:18 PM Mojca Miklavec Groenhuis > > <moj...@gm...> wrote: > > > On Thu, 11 Sept 2025, 00: 45 Ethan A Merritt, <merritt@ uw. edu> > > > wrote: On Wed, Sep 10, 2025 at 11: 35 AM Juhász Péter > > > <peter. juhasz83@ gmail. com> wrote: The error message means that > > > the certificate required to serve the site over HTTPS > > > ZjQcmQRYFpfptBannerStart > > > > > > > > > > > > This Message Is From an Untrusted Sender > > > > > > You have not previously corresponded with this sender. > > > > > > See https://itconnect.uw.edu/email-tags for additional information. > > > Please contact the UW-IT Service Center, he...@uw... 206.221.5000, > > > for assistance. > > > > > > > > > > > > > > > ZjQcmQRYFpfptBannerEnd > > > > > > > > > On Thu, 11 Sept 2025, 00:45 Ethan A Merritt, <me...@uw...> > > > wrote: > > > > > > > > > > > > On Wed, Sep 10, 2025 at 11:35 AM Juhász Péter > > > > <pet...@gm...> wrote: > > > > > > > > > > The error message means that the certificate required to serve > > > > > the site over HTTPS is not valid for the domain name > > > > > gnuplot.info [1] (nor https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!gtNM2Sc78gL-Ysg1zk84my1iRsUDO5YKxseY7vQ_6VDym0S2hHL0HhcytN_F1Emi3Mk6-vt_iZU8RIDoRuWGjXY$ [2]). If you look at the > > > > > certificate (offered by Firefox next to the error message), you > > > > > can see that it was issued by Let's Encrypt to > > > > > secureprojects.sourceforge.net [3], and it is valid for a large > > > > > selection of other domain names, presumably all projects hosted > > > > > by SF. > > > > > > > > > > > > > > > > > Thank you for your insights. > > > > > > > > I think you are addressing a different issue - whether the > > > > connection protocol is https or http. > > > > > > Yes, this is not about DNS failure. I don't experience DNS failure, > > > but see precisely the same errors/issues as Peter described. > > > > > > (Nowadays http should actually redirect to https. Modern browsers > > > also refuse to show http pages.) > > > > > > > It is not surprising that a certificate issued to SourceForge > > > > would not mention gnuplot.info [1] by name because that name is > > > > not connected to SourceForge except in that (as I understand it) > > > > it currently redirects queries to the actual gnuplot site > > > > gnuplot.sourceforge.net [4]. > > > > > > Except that it does matter for https. The hosting site needs to > > > know that the certificate should also be for gnuplot.info [1] and > > > it needs to be explicit whether that is with or without www (or > > > both). > > > Either a separate certificate is needed for that, or the > > > certificate used needs to be made aware that it needs to cover > > > gnuplot.info [1]. This really needs to be fixed on the hosting > > > site, and usually the person in charge of the DNS is also needed in > > > the process of making it work. > > > > > > Unless the administrators of gnuplot on SF have access to > > > certificate settings (means you would also need to create and > > > extend your own certificate), then SF support is really needed here > > > to set it up. > > > > > > > The current problem seems to be that the redirection itself fails > > > > in some cases, or fails to pass through sufficient information > > > > > > No. It's really a misconfigured site/certificate. > > > > > > > You still see the site, correct? > > > > > > Well ... yes and no, but the more correct answer is probably NO. By > > > default you don't see the site because the web browser is > > > protecting you from "the malicious site" until you approve an > > > exception and security risk, but that is "an advanced use" (it is > > > on purpose made difficult to do that). > > > > > > > For completeness I should mention that the issue of connection > > > > via IPv6 as opposed to IPv4 was raised earlier, and might be > > > > relevant, > > > > > > It is possible that the site works correctly on IPv4 and fails with > > > IPv6. My network right now doesn't support IPv6, so it's hard for > > > me to check. It is unrelated to certificate issues, but it could > > > hypothetically explain why DNS works for others and not for you if > > > you have IPv6. (By correctly I mean resolving to the correct > > > website. It still doesn't serve a compliant certificate.) > > > > > > Mojca > > > > > > > > > > [1] gnuplot.info > https://urldefense.com/v3/__http://gnuplot.info__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODc4D2Pme$ > [2] https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!gtNM2Sc78gL-Ysg1zk84my1iRsUDO5YKxseY7vQ_6VDym0S2hHL0HhcytN_F1Emi3Mk6-vt_iZU8RIDoRuWGjXY$ > https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!hZAtTCSEA3UZsTRDYd1Rlg-J8_Oq7DJZg-cJMaMoMBMcyZx3lwvCVqHE401p-ZikRUWZruc71FaDNhZkYYE3tw4$ > [3] secureprojects.sourceforge.net > https://urldefense.com/v3/__http://secureprojects.sourceforge.net__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODadFrph0$ > [4] gnuplot.sourceforge.net > https://urldefense.com/v3/__http://gnuplot.sourceforge.net__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODckxZJT_$ > -- Ethan A Merritt Department of Biochemistry University of Washington, Seattle |
|
From: Clark G. <cla...@gm...> - 2025-09-13 02:41:37
|
It does include subdomain 😁 I have DNS in Hover and I don't think I pay anything beyond the domains. I'll have to look into what I did with test -- it's so long since I set it up. I removed the AAAA record on the main domain for now. That shouldn't be giving a cert error no matter what -- it'll either work or not. Years ago I had this janky setup with the AAAA pointing to a server I had at VT that got a daily rsync. Definitely not tls friendly, but it gave us IPv6 and actually performed a lot better than SF. But that setup is long gone. I was thinking SF had a legit IPv6 service and that's what I configured, but that was at least a few years ago. I think I'll have some time this weekend to unpack all that and remind myself how this was supposed to work. SF not having IPv6 in 2025 is pretty inexcusable, but then they're up there with GitHub.... Again, I seem to recall they had an IPv6 approach a few years ago when I set it up but I'll refresh my memory. In the meantime I've (begrudgingly) removed the AAAA. But as far as the domain, yes I've prepaid 10 years (I think it's actually renewed once)... Cheers --ckg Clark Gaylord cla...@gm... On Thu, Sep 11, 2025, 14:12 Ethan A Merritt <me...@uw...> wrote: > On Thursday, 11 September 2025 10:08:31 PDT Juhász Péter wrote: > > The plot thickens. > > > > I wanted to check on crt.sh (a certificate search facility) what certs > > were issued for gnuplot.info in the past. To my surprise, I didn't find > > any. However, they list test.gnuplot.info (and www.test.gnuplot.info) > > for which a certificate was issued first on 2024-03-02 and renewed ever > > since. And indeed, test.gnuplot.info does work with https. > > > > I did not know that this domain exists. Should it? > > Peter > > > I think Clark Gaylord may be the best, if not the only, person to answer > this. > (CC'ed on this reply). > > Clark said last month that the gnuplot.info domain was set up > "on ten year pre payment with auto renew". > I don't know whether that includes subdomains or not. > Please excuse my ignorance. I don't even know what a "certificate" means > in this context, or how it fits in with domain registration. > > Anyhow, sourceforge supprt has acknowledged the request I made to > them to enable https for gnuplot.info so that may yet take care of it. > If there is something else I should ask them for, please let me know. > > Ethan > > > > On Wed, 2025-09-10 at 20:17 -0700, Ethan A Merritt wrote: > > > Thanks for the pointers. > > > > > > After poking around in the SourceForge admin pages I found a place to > > > set up "virtual domains". Both gnuplot.info and www.gnuplot.info are > > > already listed there. That same page states that https access can be > > > enabled by request, so I placed a support request with the > > > SourceForge site itself to enable https access via gnuplot.info and > > > www.gnuplot.info. We'll see what happens. > > > > > > Support tracker: > > > https://sourceforge.net/p/forge/site-support/27031/ > > > Ethan > > > > > > > > On Wed, Sep 10, 2025 at 5:18 PM Mojca Miklavec Groenhuis > > > <moj...@gm...> wrote: > > > > On Thu, 11 Sept 2025, 00: 45 Ethan A Merritt, <merritt@ uw. edu> > > > > wrote: On Wed, Sep 10, 2025 at 11: 35 AM Juhász Péter > > > > <peter. juhasz83@ gmail. com> wrote: The error message means that > > > > the certificate required to serve the site over HTTPS > > > > ZjQcmQRYFpfptBannerStart > > > > > > > > > > > > > > > > This Message Is From an Untrusted Sender > > > > > > > > You have not previously corresponded with this sender. > > > > > > > > See https://itconnect.uw.edu/email-tags for additional information. > > > > Please contact the UW-IT Service Center, he...@uw... 206.221.5000, > > > > for assistance. > > > > > > > > > > > > > > > > > > > > ZjQcmQRYFpfptBannerEnd > > > > > > > > > > > > On Thu, 11 Sept 2025, 00:45 Ethan A Merritt, <me...@uw...> > > > > wrote: > > > > > > > > > > > > > > > On Wed, Sep 10, 2025 at 11:35 AM Juhász Péter > > > > > <pet...@gm...> wrote: > > > > > > > > > > > > The error message means that the certificate required to serve > > > > > > the site over HTTPS is not valid for the domain name > > > > > > gnuplot.info [1] (nor > https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!gtNM2Sc78gL-Ysg1zk84my1iRsUDO5YKxseY7vQ_6VDym0S2hHL0HhcytN_F1Emi3Mk6-vt_iZU8RIDoRuWGjXY$ > [2]). If you look at the > > > > > > certificate (offered by Firefox next to the error message), you > > > > > > can see that it was issued by Let's Encrypt to > > > > > > secureprojects.sourceforge.net [3], and it is valid for a large > > > > > > selection of other domain names, presumably all projects hosted > > > > > > by SF. > > > > > > > > > > > > > > > > > > > > > Thank you for your insights. > > > > > > > > > > I think you are addressing a different issue - whether the > > > > > connection protocol is https or http. > > > > > > > > Yes, this is not about DNS failure. I don't experience DNS failure, > > > > but see precisely the same errors/issues as Peter described. > > > > > > > > (Nowadays http should actually redirect to https. Modern browsers > > > > also refuse to show http pages.) > > > > > > > > > It is not surprising that a certificate issued to SourceForge > > > > > would not mention gnuplot.info [1] by name because that name is > > > > > not connected to SourceForge except in that (as I understand it) > > > > > it currently redirects queries to the actual gnuplot site > > > > > gnuplot.sourceforge.net [4]. > > > > > > > > Except that it does matter for https. The hosting site needs to > > > > know that the certificate should also be for gnuplot.info [1] and > > > > it needs to be explicit whether that is with or without www (or > > > > both). > > > > Either a separate certificate is needed for that, or the > > > > certificate used needs to be made aware that it needs to cover > > > > gnuplot.info [1]. This really needs to be fixed on the hosting > > > > site, and usually the person in charge of the DNS is also needed in > > > > the process of making it work. > > > > > > > > Unless the administrators of gnuplot on SF have access to > > > > certificate settings (means you would also need to create and > > > > extend your own certificate), then SF support is really needed here > > > > to set it up. > > > > > > > > > The current problem seems to be that the redirection itself fails > > > > > in some cases, or fails to pass through sufficient information > > > > > > > > No. It's really a misconfigured site/certificate. > > > > > > > > > You still see the site, correct? > > > > > > > > Well ... yes and no, but the more correct answer is probably NO. By > > > > default you don't see the site because the web browser is > > > > protecting you from "the malicious site" until you approve an > > > > exception and security risk, but that is "an advanced use" (it is > > > > on purpose made difficult to do that). > > > > > > > > > For completeness I should mention that the issue of connection > > > > > via IPv6 as opposed to IPv4 was raised earlier, and might be > > > > > relevant, > > > > > > > > It is possible that the site works correctly on IPv4 and fails with > > > > IPv6. My network right now doesn't support IPv6, so it's hard for > > > > me to check. It is unrelated to certificate issues, but it could > > > > hypothetically explain why DNS works for others and not for you if > > > > you have IPv6. (By correctly I mean resolving to the correct > > > > website. It still doesn't serve a compliant certificate.) > > > > > > > > Mojca > > > > > > > > > > > > > > > > [1] gnuplot.info > > > https://urldefense.com/v3/__http://gnuplot.info__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODc4D2Pme$ > > [2] > https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!gtNM2Sc78gL-Ysg1zk84my1iRsUDO5YKxseY7vQ_6VDym0S2hHL0HhcytN_F1Emi3Mk6-vt_iZU8RIDoRuWGjXY$ > > > https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!hZAtTCSEA3UZsTRDYd1Rlg-J8_Oq7DJZg-cJMaMoMBMcyZx3lwvCVqHE401p-ZikRUWZruc71FaDNhZkYYE3tw4$ > > [3] secureprojects.sourceforge.net > > > https://urldefense.com/v3/__http://secureprojects.sourceforge.net__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODadFrph0$ > > [4] gnuplot.sourceforge.net > > > https://urldefense.com/v3/__http://gnuplot.sourceforge.net__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODckxZJT_$ > > > > > -- > Ethan A Merritt > Department of Biochemistry > University of Washington, Seattle > > > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X