Skip to main content
Topic: Cannot access Artix' sources/PKGBUILDs: gitea.[...] / packages.artixlinux.org (Read 1841 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Cannot access Artix' sources/PKGBUILDs: gitea.[...] / packages.artixlinux.org

Code: [Select]
META: I don't know why this post gets malformatted every time, the forum inserts a "code"-tagat the very beginning, every time I edit the post and remove it it get's re-inserted.

---

Ahoj,

I cannot access the Artix packages' sources/ [tt]PKGBUILD[/tt]s:

https://gitea.artixlinux.org/ does not connect[1],
on https://packages.artixlinux.org/details/mkinitcpio, clicking on "[url=View Package Sources]View Package Sources[/url]" just shows the same page again.

[1] [tt]wget -O /dev/null https://gitea.artixlinux.org/[/tt]:
[ code]
--2022-12-04 22:07:21--  https://gitea.artixlinux.org/
Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt'
Resolving gitea.artixlinux.org (gitea.artixlinux.org)... 84.46.83.154
Connecting to gitea.artixlinux.org (gitea.artixlinux.org)|84.46.83.154|:443... connected.
GnuTLS: The TLS connection was non-properly terminated.
Unable to establish SSL connection.

In the Web Browser (Firefox):
Secure Connection Failed

An error occurred during a connection to gitea.artixlinux.org. PR_END_OF_FILE_ERROR

Error code: PR_END_OF_FILE_ERROR

  • The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
  • Please contact the website owners to inform them of this problem.

Re: Cannot access Artix' sources/PKGBUILDs: gitea.[...] / packages.artixlinux.org

Reply #1
I don't know why this post gets malformatted every time, ...
---
I cannot access the Artix packages' sources ...

I would use another browser.
"Wer alles kann, macht nichts richtig"

Artix USE="runit openrc slim openbox lxde gtk2 qt4 qt5 qt6 conky
-gtk3 -gtk4 -adwaita{cursors,themes,icons} -gnome3 -kde -plasma -wayland "

Re: Cannot access Artix' sources/PKGBUILDs: gitea.[...] / packages.artixlinux.org

Reply #2
Chromium works, curl works after multiple low timeout retries and wget works over Tor ( although consider the fact the internet isn't the best here hence why curl and wget were done like that )

Have you upgraded your system fully or done a partial upgrade?

Re: Cannot access Artix' sources/PKGBUILDs: gitea.[...] / packages.artixlinux.org

Reply #3

Sorry, guys, if I use an up to date Firefox (version 108.0b9), then it is not the browser to blame.

Chromium works, curl works after multiple low timeout retries and wget works over Tor ( although consider the fact the internet isn't the best here hence why curl and wget were done like that )

Sorry, guys, when it works only after multiple timeouts and only from specific IP adresses or so, than I consider it as "not working", since it is meant to be generally accessible.

I am going to Internet via nordvpn in Zürich.

Have you upgraded your system fully or done a partial upgrade?

Full upgrade.

Re: Cannot access Artix' sources/PKGBUILDs: gitea.[...] / packages.artixlinux.org

Reply #4
would you enlighten me

what happens when you go to this url trough you browser
https://gitea.artixlinux.org/packagesM/mkinitcpio/src/branch/master/trunk/PKGBUILD

and what will be the output of this
Code: [Select]
 curl -LO https://gitea.artixlinux.org/packagesM/mkinitcpio/raw/branch/master/trunk/PKGBUILD
or the wget equivalent

 

Re: Cannot access Artix' sources/PKGBUILDs: gitea.[...] / packages.artixlinux.org

Reply #5
if this doesn't work

# first try reinstalling "certificate" packages (it may not fix anything).
Code: [Select]
pacman -S ca-certificates ca-certificates-mozilla ca-certificates-utils

# if it doesn't work debug your network properly.
 * ping the website
 * resolve the domain
 * trace the package route
more about it here

Re: Cannot access Artix' sources/PKGBUILDs: gitea.[...] / packages.artixlinux.org

Reply #6

Attached screenshot from Firefox Developer Edition, version 108.0b9:



Same in a private window.

Attached screenshot from Ungoogled Chromium, version 107.0.5304.121:



and what will be the output of this
Code: [Select]
 curl -LO https://gitea.artixlinux.org/packagesM/mkinitcpio/raw/branch/master/trunk/PKGBUILD

Code: [Select]
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:--  0:00:12 --:--:--     0
curl: (35) error:0A000126:SSL routines::unexpected eof while reading

My IP adress according to https://iplocation.io/:

IPv4: 45.8.148.205
IPv6: Not Detected


I tested via another internet connection, IP adress according to https://iplocation.io/:

IPv4: 46.114.201.249
IPv6: Not Detected

.. there it works, as well as from IPv4: 95.90.150.190.


So the problem is somewhere on the route, but strange since other sites work. Can it be that my IP adress is somehow in some filtering list associated with gitea.artixlinux.org and packages.artixlinux.org?

if this doesn't work

# first try reinstalling "certificate" packages (it may not fix anything).
Code: [Select]
pacman -S ca-certificates ca-certificates-mozilla ca-certificates-utils

Skipped, since via another internet access it works.

# if it doesn't work debug your network properly.
 * ping the website
ping -c2 gitea.artixlinux.org:
Code: [Select]
PING taurus.artixlinux.org (84.46.83.154) 56(84) bytes of data.
64 bytes from 84.46.83.154 (84.46.83.154): icmp_seq=1 ttl=53 time=59.6 ms
64 bytes from 84.46.83.154 (84.46.83.154): icmp_seq=2 ttl=53 time=61.4 ms

--- taurus.artixlinux.org ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 59.584/60.511/61.438/0.927 ms

dig gitea.artixlinux.org:
Code: [Select]

; <<>> DiG 9.18.9 <<>> gitea.artixlinux.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38496
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;gitea.artixlinux.org. IN A

;; ANSWER SECTION:
gitea.artixlinux.org. 237 IN CNAME taurus.artixlinux.org.
taurus.artixlinux.org. 237 IN A 84.46.83.154

;; Query time: 0 msec
;; SERVER: 192.168.100.253#53(192.168.100.253) (UDP)
;; WHEN: Tue Dec 06 12:27:05 CET 2022
;; MSG SIZE  rcvd: 100



tracepath -n gitea.artixlinux.org:
Code: [Select]
 1?: [LOCALHOST]                      pmtu 1500
 1:  192.168.100.253                                       8.235ms
 1:  192.168.100.253                                       3.931ms
 2:  10.8.2.1                                             45.924ms
 3:  no reply
 4:  no reply
 5:  193.27.15.34                                         57.695ms
 6:  37.120.220.110                                       62.813ms asymm 14
 7:  no reply
 8:  no reply
 9:  82.102.29.233                                        61.189ms
10:  176.10.83.119                                        59.981ms asymm 11
11:  80.249.211.221                                       59.661ms asymm  9
12:  84.46.113.252                                        70.953ms
13:  84.46.113.33                                         70.027ms asymm 11
14:  no reply
15:  no reply
16:  no reply
17:  no reply
18:  no reply
19:  no reply
20:  no reply
21:  no reply
22:  no reply
23:  no reply
24:  no reply
25:  no reply
26:  no reply
27:  no reply
28:  no reply
29:  no reply
30:  no reply
     Too many hops: pmtu 1500
     Resume: pmtu 1500

tracepath gitea.artixlinux.org:
Code: [Select]
 1?: [LOCALHOST]                      pmtu 1500
 1:  opiplus                                               2.374ms
 1:  opiplus                                               1.967ms
 2:  10.8.2.1                                             43.982ms
 3:  no reply
 4:  no reply
 5:  193.27.15.36                                         63.373ms
 6:  xe-2-2-3-0.core1.fra2.de.m247.com                    57.241ms asymm 14
 7:  no reply
 8:  vlan2913.bb1.ams1.nl.m247.com                        74.383ms asymm 12
 9:  ae2-1000.core1.ams2.nl.m247.com                      55.871ms
10:  176.10.83.119                                        58.130ms asymm 11
11:  ams-ix.b6777.Kermit.ipv4.wtnet.de                    60.723ms asymm  9
12:  b31040.Bibo.ipv4.wtnet.de                            73.500ms
13:  b99.pop104-asr.ipv4.wtnet.de                         64.719ms asymm 11
14:  no reply
15:  no reply
16:  no reply
17:  no reply
18:  no reply
19:  no reply
20:  no reply
21:  no reply
22:  no reply
23:  no reply
24:  no reply
25:  no reply
26:  no reply
27:  no reply
28:  no reply
29:  no reply
30:  no reply
     Too many hops: pmtu 1500
     Resume: pmtu 1500

Do this information somehow help to track the problem down?

---

And now I had it once when trying to access the forum, that I got a Error 502 "Bad Gateway" with a cloudflare website:



(Reloading and it worked again.)

---

Regarding the forum: When I want to write in this thread, I see a message at the top saying

Quote from: Messag of the forum
Warning! This topic is currently/will be locked
Only admins and moderators can reply.


But I nevertheless can reply. What is wrong here?

Re: Cannot access Artix' sources/PKGBUILDs: gitea.[...] / packages.artixlinux.org

Reply #7
If you try searching the error (which is quicker than trying to rewrite it all here) something like "PR_END_OF_FILE_ERROR secure connection failed firefox" then it returned various helpful suggestions and explanations, e.g. :
https://support.mozilla.org/en-US/questions/1267074
https://superuser.com/questions/1492755/what-does-the-pr-end-of-file-error-error-mean-in-firefox
It suggests the cipher used by the website is not supported by your VPN server which makes the connection on your behalf, so it might also be helpful to report it to your VPN provider. Perhaps they intentionally don't support it for security reasons or perhaps it is newer than their update status, or something else, who knows. I don't know if it has any relevance but https involves a third party web address which validates the certificate, so possibly that could be involved too, although I didn't see anything mentioning it from briefly looking at some of those search results.

VPN != (?) proxy/ man in the middle(?)

Reply #8
It suggests the cipher used by the website is not supported by your VPN server which makes the connection on your behalf,

that would mean that the VPN server is not a VPN server but a proxy which acts as a man in the middle in the HTTPS connection.

I have a proper network device for the VPN, and my webbrowser connects directly to the target site. So if your statement is true it must mean that the "VPN" server would intercept the connection as a man in the middle.

That should be detectable by looking at the certificates I get, because a man in the middle cannot forge a certificate (if the original server's private key has not leaked).

I don't know if it has any relevance but https involves a third party web address which validates the certificate, so possibly that could be involved too, although I didn't see anything mentioning it from briefly looking at some of those search results.

Hm, maybe some third party validation request not working here?

Is there a way I can exclude that Artix' servers refuse to serve said IP adress (range) correctly?

Re: Cannot access Artix' sources/PKGBUILDs: gitea.[...] / packages.artixlinux.org

Reply #9
Sorry, guys, if I use an up to date Firefox (version 108.0b9), then it is not the browser to blame.

Your browser it's the cause perhaps a nightly built. In those nightly builds they try fixing some ff open bugs and it looks like the bug or other related problem wasn't fixed.

Re: Cannot access Artix' sources/PKGBUILDs: gitea.[...] / packages.artixlinux.org

Reply #10
If it was the browser why is curl also failing?

It's the VPN.

Re: Cannot access Artix' sources/PKGBUILDs: gitea.[...] / packages.artixlinux.org

Reply #11
Yeah VPN is the cause.

I've tested with this website

Looks like gitea rejects everything bellow tls1.3 and tls1.2 an sends  "fatal alert: handshake_failure"

Perhaps VPN advertise some lower than tls 1.3/1.2 protocol so because gitea does not agree it gives handshake error. Most likely the VPN uses lower standards for higher efficiency. My conclusion is the VPN must be configured to accept higher protocol standards to fix the problem.


How can a VPN look into the connection? Artix' Server blocking VPN IP?

Reply #12
Yeah VPN is the cause.

I've tested with this website

Looks like gitea rejects everything bellow tls1.3 and tls1.2 an sends  "fatal alert: handshake_failure"

Perhaps VPN advertise some lower than tls 1.3/1.2 protocol so because gitea does not agree it gives handshake error. Most likely the VPN uses lower standards for higher efficiency. My conclusion is the VPN must be configured to accept higher protocol standards to fix the problem.

I have a big confusion now: Why does the VPN interfere in any way? It can only do if it would hijack the SSL connection. But that I would recognise on other sites due to false certificates. The only thing I can see is that the VPN can block the connection totally, but not interfere with the TLS handshake or connection. Can you enlighten me?

This: Reddit thread "Suddenly unable to access any Google services with an active VPN." suggests that something might also be blocking NordVPN IP adresses on the server side -- there it is google blocking known NordVPN IPs.

I have tested what was suggested there to try another NordVPN server, and there I can access https://gitea.artixlinux.org/ via a brazilian NordVPN server (IP adress: 189.1.170.176).

So, the question remains: How can I rule out that something on the server side of the Artix' servers or datacenter or their content delivery network is just blocking the IP range in question? And if it is: They should change this.

Re: Cannot access Artix' sources/PKGBUILDs: gitea.[...] / packages.artixlinux.org

Reply #13
 
Another VPN, different server that has higher protocol standards that meet gitea requirements that's why it works. When you use VPN your connection is not negotiated client side (ff) but involves VPN configuration so even your ff is ok VPN standards has to be properly configured.

When you use VPN your connection (handshake) to any website is done between VPN server that encapsulates (hides) all that in its payload  and gitea or whatever website you are trying to reach. You just receive data already negotiated by you current VPN server.

It has nothing to do with ip blocking or other restrictions.

You can check your client which in case you use VPN your client is your VPN server in use. TEST HERE


Re: Cannot access Artix' sources/PKGBUILDs: gitea.[...] / packages.artixlinux.org

Reply #14
I have a big confusion now: Why does the VPN interfere in any way? It can only do if it would hijack the SSL connection.

My understanding. It doesn't hijack the SSL connection. It makes the SSL connection. Then what is received back it sends to you through the VPN tunnel. You are not getting a VPN tunnel from your computer / router to the website. The VPN tunnel is just between you and the VPN server.

Disclaimer: I'm no expert and that's probably an oversimplification.

Edit: On the way to the shop and back I'm thinking that can't be right either ? IDK. I've a big confusion as well. I'll give it some thought.