Append triffid/pia-wg to 3rd party repository table

[triffid]

I've formalised my old gist into a proper repository.

My scripts are designed to act more like a proper system service than PIA's manual-connection scripts, in that they use a config file, a proper cache location, can reuse cached link information, can set up routing tables and ip rules that can assist with customised split-routing setups, do more error checking, and do not require DNS after the initial cache fill procedure.

They're also capable of generating configs for other devices instead of only affecting the device on which they're run, and can even drop a QR code onto the terminal for use with WireGuard's Android app (and probably the iOS app too but I haven't tried).

[g00nix]

I think the System should be Linux/Android. What do you think?

[triffid]

The scripts cannot run on android since it's userland lacks jq, but I'm willing to add android/iOS in parentheses if you like

iIt might be preferable to add a "comments" column for this sort of information so folks don't get confused though - that way I can write "can generate configs for routers and wireguard's mobile apps" while leaving the system retirement as just "Linux"

[g00nix]

Good point. I think we can merge, but please respect the alphabetical order based on System.

[triffid]

I didn't realise the table was ordered, I'll fix that

[g00nix]

@triffid I checked your config now and I saw it has no readme or comments in the code. If people click on it they actually expect to have an easy to use script that will spit out a config for WireGuard for Android. You can do cat wg.conf | qrencode -t ANSIUTF8 and scan it with your phone.

[triffid]

So you'd like me to add a readme before adding my repo to your list?

I can do that, probably should have put one a while ago actually.

PS: were you looking for https://github.com/triffid/pia-wg/blob/master/pia-wg.sh#L315-L318 ?

[g00nix]

PS: were you looking for https://github.com/triffid/pia-wg/blob/master/pia-wg.sh#L315-L318 ?

Sorry, I didn't notice you were already doing that. This proves that a readme can help people to get a better overview 😆

[triffid]

I added a README to my repo, let me know what you think!

Anything else you'd like before you merge this pull?

[g00nix]

is a VPN provider that claims a strict interest in privacy and claims to not log user traffic.

We proved in court that we have no logs. I am not sure if this information is relevant for a readme on github.

These scripts are carefully designed to not need working DNS after the initial setup, since they were written for places where PIA is ostensibly blocked.
During initial setup in such places however, you'll have to use an alternate connection method so that the auth token can be fetched from PIA's API, and the initial serverlist and PIA encryption key can be grabbed from github

To avoid this issue, you should also have a look at the meta IPs provided the serverlist. They allow you to access the serverlist and to the API without DNS requests and without sending the SNI in the TLS hello (cause if they really try to block you they will also check the SNI). You can find an example here: https://github.com/pia-foss/manual-connections/blob/v0.1.0/get_region_and_token.sh

This should allow you to get the serverlist and also get a token without getting blocked.

[...] big paragraph about token confusion [...]

You WireGuard public key will get deleted from the servers after a few hours of inactivity. If you add keepalive to your WireGuard, your public key will be kept on the server till the server gets restarted. Since no data gets saved to disk, a power cycle means that all software needs to get redeployed to the server. Servers will get restarted every few months to make sure we always use the latest software.

The tokens generated by this script will expire after one day. You should not create any automation that attempts to use the scripts for any longer period, as that will fail. Please do not confuse the tokens generated by these scripts with the tokens generated by the apps, as they are totally different. The tokens generated by the apps have a longer lifetime.

If your router gets disconnected, the best way to proceed is to get a new token, create a new WireGuard key, and create a new WireGuard connection (go through the entire process). The automation should be designed to gracefully handle disconnections, as the servers can lose power or internet. I know this is not the best case, since these scripts don't work on DDWRT or OpenWRT. We have a plan to improve the quality of the service for routers.

[triffid]

We proved in court that we have no logs. I am not sure if this information is relevant for a readme on github.

I'm also not sure if it's within scope which is why I didn't go into detail, but y'all have a pretty strong claim that's easy to find if folks want to dig further ;)

Perhaps I'll link that phrase to one of your publications on the topic.

Does PIA have an anti gag order canary somewhere?

To avoid this issue, you should also have a look at the meta IPs provided the serverlist.

I didn't spot the meta servers when I was setting things up, and didn't discern their purpose later when I did spot them; guess I can re-jig my script a bit.

If a token is generated through a meta server, is it valid on all other servers (eg if a new location is chosen after token fetch)? What's the typical propagation delay?

It would be nice if there was a README for PIA's API :P

[...] big paragraph about token confusion [...]

Thanks for the clarifications on PIA's backend, I haven't found this information published anywhere before.

I've been using the same token for 7 months - if they're supposed to expire in 24 hours, y'all have a bug.

Does the token expiry schedule mean I need to store the PIA customer password unobfuscated? I'd much prefer if that wasn't necessary..

It would be really nice if wireguard configurations didn't require keepalive, specifically for things like phones and routers that may not have 24/7 internet access - I'd actually prefer if it worked according to my erroneous description.

I'll update my README according to the information you've provided, and examine making token refetch more automated.

If I fetch a new token in less than 24 hours, what happens?

Does that mean PIA's current infrastructure allows someone to generate a large number of wireguard connection configurations exceeding the 10 device limit (pulling new tokens if necessary) and have them all simultaneously active?

--

Other than revamping my README, are there any other impediments to merging this pull?

Also, have you vetted the other items in the 3rd party repo list this thoroughly?

[triffid]

I pushed an update to my repo's README

[g00nix]

Awesome work, this looks great!