All Activity
This stream auto-updates
- Past hour
-
-
-
-
-
-
-
-
-
-
- Today
-
-
Thanks for the clarification @Staff!
-
-
-
Starting from February 1st, 2026, Debian (e.g. Trixie) enforces stricter OpenPGP policies and no longer accepts repository signatures involving SHA1-based certifications. As a result, users may see errors such as: Get:4 http://eddie.website/repository/apt stable InRelease [3,954 B] Err:4 http://eddie.website/repository/apt stable InRelease Sub-process /usr/bin/sqv returned an error code (1), error message is: Signing key on C181AC89FA667E317F423998513EFC94400D7698 is not bound: No binding signature at time 2025-01-14T13:07:46Z because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance because: SHA1 is not considered secure since 2026-02-01T00:00:00Z Warning: OpenPGP signature verification failed: http://eddie.website/repository/apt stable InRelease: Sub-process /usr/bin/sqv returned an error code (1), error message is: Signing key on C181AC89FA667E317F423998513EFC94400D7698 is not bound: No binding signature at time 2025-01-14T13:07:46Z because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance because: SHA1 is not considered secure since 2026-02-01T00:00:00Z Error: The repository 'http://eddie.website/repository/apt stable InRelease' is not signed. Notice: Updating from such a repository can't be done securely, and is therefore disabled by default. Notice: See apt-secure(8) manpage for repository creation and user configuration details. This was caused by an outdated signing key certification used by the repository. Solution The repository signing key has been regenerated and the repository is now correctly signed again. To restore updates, please re-import the updated maintainer key: curl -fsSL https://eddie.website/repository/keys/eddie_maintainer_gpg.key | sudo tee /usr/share/keyrings/eddie.website-keyring.asc > /dev/null Then run: sudo apt update Sorry for the inconvenience, and thanks for your patience. Kind regards
-
Dje_ reacted to a post in a topic:
Debian Trixie: apt update fails for Eddie repo since 2026-02-01 (SHA1 rejected) ...
-
Dje_ reacted to a post in a topic:
Debian Trixie: apt update fails for Eddie repo since 2026-02-01 (SHA1 rejected) ...
-
Hello! Interesting thread indeed, thank you. Our position is close to the EFF position you can read here: https://www.eff.org/deeplinks/2025/08/no-uks-online-safety-act-doesnt-make-children-safer-online We will keep you informed. So far, you probably know well our approach with similar, lower or higher requests from Russia, China and a few other countries, and there's no plan at the moment to change our position. In general, we think that it is impossible that those persons who advance, propose or defend such dangerous laws in so called democracies are in good faith (except in peculiar cases where they suffer from some mental illness or carry a neurological deficit). They have an hidden agenda developed on the myth of pervasive control but more importantly fueled by monetary reward. Yes, that's a motivational reason, maybe almost as strong as monetary reward and votes. Moreover, there is a real possibility that such laws lead on the short run to an increase in support (and therefore votes) which, net of dissent, is positive, even though by tiny tenths of percentage which are anyway not negligible for an embarrassingly inept ruling class that's incapable of developing serious strategies to improve the life of teenagers and children. Their total failure is proven by the official data (England and Whales police records in this case) that show a dramatic rise of sexual offenses against children in the UK in the last 5 years in spite of (and someone could even argue because of) more and more laws allegedly thought to protect children. Where does this 0.1% come from? If you want to stay real please adjust this quota (since 2025, start multiplying that percentage by 250 to begin with). Furthermore, there's no money involved to use Tor, its usage is totally free and well beyond Ofcom abilities to control it. However, it's true that people may find it boring because it's like 10 times slower than a VPN with a decent infrastructure. It would indeed. However, we seriously doubt that the ramshackle British institutions, always short of funds, can surpass the GFW designers and maintainers in efficiency, competence and grandeur of operation. And note that the GFW is routinely bypassed nowadays by the most and least skilled to connect to a wide range of VPNs. Our aggregate data show that this claim is deeply incorrect, at least for AirVPN, if we consider p2p improper usage quantified by DMCA and other warnings. It's not the majority, on the contrary it is a tiny minority. Where does this assumption come from? We would like to assess official stats to compare them with what we gather on the field. Kind regards
-
If we are "staying real" let's think back of when we were children ourselves: When did ANYTHING that was impose by parents/etc on you worked? Children will always find ways around the the forbidden thing usually way riskier and dangerous than the thing supposed to be protected from. This "protect the children" pish is just gas lighting from the government to monitor who does what. Governments cannot stand that they don't control the narrative anymore and that people use the internet to bypass them, no matter on which side of the politics spectrum you are. The burden is with the parents to protect their children, not daddy government. Parents who support it, need to stop relying on the internet to babysit and raise their children.
-
Thanks for the detailed reply. Lots of interesting points. It seems to me that people using VPNs are interested in privacy and anonymity, which conflicts with the government's ideas about age verification in order to use VPNs, regardless of what people are actually using the VPN service to do. I would also imagine VPN companies with a strong privacy focus would be opposed on principle. I would be interested to hear what AirVPNs official position is regarding the UK's proposals here, and what they plan to do. Interesting point, I hadn't considered this. Would this not entail an on-going cat-and-mouse effort with the government legally pressuring ISPs to block IPs? Sounds like a lot of work and expense. I wonder if anyone in government is thinking in this much detail and clarity, I had assumed they probably don't understand the technical side very well.
-
-
airxirtir reacted to a post in a topic:
Debian Trixie: apt update fails for Eddie repo since 2026-02-01 (SHA1 rejected) ...
-
Sure, in order to protect kids China / Iran / Russia style enforcement is required. 🙄 Because nothing screams “online safety” like forcing teenagers roam the internet without a VPN. What could possibly go wrong? It’s not like tracking, data harvesting, or privacy breaches are a thing.
-
guest34875 reacted to a post in a topic:
Debian Trixie: apt update fails for Eddie repo since 2026-02-01 (SHA1 rejected) ...
-
-
-
BettyIsBoop reacted to a post in a topic:
Debian Trixie: apt update fails for Eddie repo since 2026-02-01 (SHA1 rejected) ...
-
BettyIsBoop reacted to a post in a topic:
Debian Trixie: apt update fails for Eddie repo since 2026-02-01 (SHA1 rejected) ...
-
OSA I am very familiar with (I read the entire 50 page guide for starters and work with companies that have to comply with it) and it's actually quite reasonable for companies/entities "in scope" to comply with age verification. That VPNs were the loophole and that it is more than obvious that sooner or later Ofcom will plug it by making VPN providers that service UK "in scope" and yes, this includes AirVPN and all other ones of note. (it's possible for a company to be of an "in scope" industry but not have qualified UK users, but unless it's a site entirely in a foreign language and clearly targeted for a specific country, the company is otherwise out of luck) It would not be difficult for Air or any other VPN to add in age assurance for users geolocating* in the UK. *Theoretically a user in the UK can use a VPN/Tor/proxy to make a paid VPN account and pay by crypto without having to verify their age but in reality this is maybe 0.1% of the userbase so let's stay real. However (and I expect to be flamed), since AirVPN promises the "air to breathe the real internet", a big issue is be it Air or any other of the big "we don't log" VPN companies, the majority of users use the service to pirate and thus don't want to be caught. A VPN provider could easily restrict ports/have a more robust policy responding to DMCA's/etc and thus gain access to wider pool of hosting companies, but their userbase uses VPNs for a certain reason that makes this not a financially effective strategy (I only know of one VPN provider that offers "clean" IPs and they do have stricter rules for them). While verifying ages for a paid service like Air won't break the bank (trust me, it won't, it's negligible for in scope paid-only companies I have worked with), very few users would want to do it. "But how can Ofcom/UK enforce this?" Easy. They can just make accounts on all the big VPN providers and periodically get entry/exit IPs of all the servers and have local ISPs block access to them if the VPN service does not comply.
- Yesterday
-
-
-
- Last week
-
-
-
Are you still working on this? Or do you plan to make it open source?
-
-
Hi AirVPN Team, Thank you very much for your detailed response and suggestions. I really appreciate the guidance. Following your advice, I tested Gluetun and qBittorrent on a different OS and server, freshly installed, and the first results look very promising — for example, I’m now seeing around 20 MiB/s downloading the Ubuntu ISO. I will continue to explore and test this setup further. I also wanted to note that I initially followed a suggestion from ChatGPT to leave FIREWALL_VPN_INPUT_PORTS unset, but of course, that was a mistake — not everything you read should be taken at face value 😉. I understand that I’ll need to reconfigure everything, but I will be using the new server endpoint: WIREGUARD_ADDRESSES=10.170.0.132/32 WIREGUARD_ENDPOINT=taiyangshou.vpn.airdns.org:1637 WIREGUARD_MTU=1280 SERVER_COUNTRIES=Netherlands FIREWALL_VPN_INPUT_PORTS=xxxx,xxxx,xxxx TZ=Europe/Amsterdam FIREWALL_OUTBOUND_SUBNETS=192.168.1.0/24 Thanks again for your support and for clarifying how the firewall rules work — it really helped me pinpoint the issue. Best regards
-
Hello! Thanks, we are aware of the problem. Unfortunately the registrar does not allow to change this setting on the authoritative DNS. For a deliberate choice, airvpn.org is one of the very few domain names we operate for which we do not manage directly the metal behind our own authoritative servers. We will anyway remind the provider of the problem as we did in the past and we will consider whether it's appropriate moving the domain name for this problem. Kind regards
-
@Peter Laanstra Hello! There isn't (and there never was) any throttling policy at all on any AirVPN server. Please test directly from the host (no containers) to quickly discern whether the problem is GlueTun specific or not. Please test different torrent software as well as smaller WireGuard interface MTU (start testing from 1280 bytes). On GlueTun, FIREWALL_VPN_INPUT_PORTS environment variable must be set properly. The fact that you unset it sounds like an error: why do you say that you don't set it to avoid firewall conflicts? This environment variable is read by the container exactly for firewall rules. If the variable is empty, no unsolicited incoming packets will be allowed on tun0 (or any other VPN interface). Please feel free to elaborate. Kind regards
-
Hi AirVPN team, I discovered that the airvpn.org domain has orphaned DS records in the .org zone that cause DNSSEC validation failures with strict resolvers. The problem: The .org registry has DS records for algorithm 8 (RSA) keys that no longer exist in the DNSKEY set: DS 28066 - Algorithm 8 (RSA) - No matching DNSKEY DS 50944 - Algorithm 8 (RSA) - No matching DNSKEY DS 51959 - Algorithm 13 (ECDSA) - Valid DS 20410 - Algorithm 13 (ECDSA) - Valid Impact: Resolvers with strict DNSSEC validation (e.g., Unbound with harden-algo-downgrade: yes) return SERVFAIL for airvpn.org because they expect DNSKEYs for all algorithms advertised in the DS records. Most public resolvers (Quad9, Cloudflare, Google) handle this gracefully, but users running their own recursive resolvers may be unable to access your website. Fix: Remove the stale DS records (key IDs 28066 and 50944) from the .org registry through your domain registrar. Verification commands: dig airvpn.org DS +short dig airvpn.org DNSKEY +short Thanks for looking into this!
-
Hi AirVPN community, I’m experiencing very low torrent speeds (max 10KiB/s) on my NL servers, despite everything being correctly configured. This is unusual because until recently, I was getting high speeds on the same setup. Setup: VPN: AirVPN, WireGuard Client: Gluetun Docker container qBittorrent: binded to interface tun0, optional IP: all addresses Forwarded port: assigned through AirVPN Client Area and verified open (TCP + UDP) MTU: 1420 Firewall settings: FIREWALL_VPN_INPUT_PORTS removed to avoid conflicts Server tried: NL2 and the new NL servers Taiyangshou / Vindemiatrix LAN: 192.168.1.0/24 allowed outbound What I observed: Speedtest in Gluetun container: 170–330 Mbit/s download, 220–260 Mbit/s upload qBittorrent: multiple torrents running with hundreds to thousands of seeds, download stuck at total max 10 KiB/s max, barely any improvement with multiple torrents. Even torrents with many seeds run at e few B/s! Forwarded port is open and correctly set in qBittorrent Everything works fine technically — Gluetun connects, WireGuard establishes, tun0 IP assigned Notes: This behavior is new sinds last week; before this, torrents downloaded at several MB/s on the same NL nodes All technical aspects of port forwarding, MTU, Docker setup have been verified Questions: Is there a new P2P throttling policy on the NL servers? Are there known issues with WireGuard and torrent throughput via Gluetun? Could there be something else limiting torrent speeds that I should check? Any insights or suggestions would be appreciated. Thanks! — Peter
-
Had this Problem yesterday too and found a Workaround. Treat this as a temporary workaround. apt uses "Sequoia PGP" to verify signatures. By default, sqv is configured to accept the SHA1 hash algorithm only until Feb 1st 2026. To Resolve this for a period of Time, reconfigure sqv, copy /usr/share/apt/default-sequoia.config to /etc/crypto-policies/back-ends/apt-sequoia.config, and change the date from 2026.02.01 to 2026.06.01 in the line the Repo should Update again until 2026.06.01, better Solution would be an updated signing Key.
-
I’m using a QNAP NAS and have set up AirVPN WireGuard as the default gateway for all network traffic. Everything works fine for outbound connections, but now I need to expose specific container ports to the local network or the internet. I’m concerned that changing any network settings might break the VPN connection. I’ve tried a few port forwarding methods, but they don’t seem to work while WireGuard is active. Has anyone successfully exposed container ports while keeping WireGuard as the default gateway? Any step-by-step instructions or tips would be greatly appreciated.
-
-
@rpoyner Hello and welcome aboard! We see the problem. First, please make sure you have downloaded Eddie notarized version exclusively from AirVPN web site. Then, you need to avoid app translocation by moving Eddie to the /Applications folder using the Finder app. Once the translocation doesn't take place anymore, please follow this message if any problem persists: https://airvpn.org/forums/topic/70745-eddie-cant-connect-to-any-server/?do=findComment&comment=249545 Kind regards
-
Hi, since 2026-02-01 my Debian Trixie system can’t update the Eddie APT repo. Debian repos are fine, only eddie.website fails. Error: http://eddie.website/repository/apt stable InRelease sqv: Policy rejected signature because SHA1 is not considered secure since 2026-02-01T00:00:00Z Key: C181AC89FA667E317F423998513EFC94400D7698 Is there an updated repo signing key / re-signed InRelease available (SHA256+), or a recommended fix/workaround until it’s updated? Thanks!
-
Cant get airvpn to connect. Attaching the error code line, something to do with wireguard, Im not too savvy at this, any help would be appreciated. E 2026.02.01 08:42:18 - WireGuard > Error: Executable '/private/var/folders/2y/7rnngmrd6fv08b226ryfpksh0000gn/T/AppTranslocation/9BF1287F-A4DC-45F3-8804-E4F4675DFC2B/d/Eddie.app/Contents/MacOS/wireguard-go' not allowed: Not owned by root;
-
Reason for Decreased MTU from 1420 to 1320
Staff replied to reversevpn's topic in General & Suggestions
Hello! No need for MSS clamping when using WireGuard, just modify the MTU if necessary. Since MSS clamping 1. becomes necessary only when you can't modify MTU, 2. needs packet mangling (WireGuard does not expose any option for it) and 3. requires anyway a server side modification, just operate through MTU. In OpenVPN (only when working over UDP), where networking management is a bit different, you can seriously consider the mssfix directive if you have any "fragmentation" problem that causes packet loss and poor performance. mssfix announces to TCP sessions running over the tunnel that they should limit their send packet sizes such that after OpenVPN has encapsulated them, the resulting UDP packet size that OpenVPN sends to its peer will not exceed max bytes. See also OpenVPN manual: https://openvpn.net/community-docs/community-articles/openvpn-2-6-manual.html In Eddie you can add custom directives for OpenVPN in "Preferences" > "OVPN Directives" window. Kind regards -
-
-
Reason for Decreased MTU from 1420 to 1320
Tommie replied to reversevpn's topic in General & Suggestions
Related to this, when selecting Wireguard in Eddie, is the MSS set to 1320 by default? If not is it recommended to add it to OVPN directives? -
Three new 10 Gbit/s servers available (CA)
iwih2gk replied to Staff's topic in News and Announcement
Its a shame. These were among the absolute fastest (especially Chumukay) when they came on board. They smoked the high powered Chicago servers but they are not reliable for the past week or two. Right across the border in Chicago apparently nobody is attacking those servers.
