The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-03-28T09:20:32Zhttps://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/145Submit Feedback link in About Mullvad Browser links to connect.mozilla.org2023-03-28T09:20:32ZrichardSubmit Feedback link in About Mullvad Browser links to connect.mozilla.orgFrom the About Mullvad Dialog, the Submit Feedback link goes to https://connect.mozilla.org . Presumably this should go to some Mullvad endpoint, or we should remove the link entirely.From the About Mullvad Dialog, the Submit Feedback link goes to https://connect.mozilla.org . Presumably this should go to some Mullvad endpoint, or we should remove the link entirely.ruihildtruihildthttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41697issue 41598, "Prevent NoScript from being removed / disabled " is not working...2023-03-28T15:55:21Zcypherpunksissue 41598, "Prevent NoScript from being removed / disabled " is not working the way you are expecting.version 12.0.4 added "Prevent NoScript from being removed / disabled until core functionality has been migrated to Tor Browser" but at least in my tor browser the NoScript add-on stay `disabled`. This is a good thing because add-ons whic...version 12.0.4 added "Prevent NoScript from being removed / disabled until core functionality has been migrated to Tor Browser" but at least in my tor browser the NoScript add-on stay `disabled`. This is a good thing because add-ons which intercept/block traffic can block each other.
Let's just keep this. If you are going to enable this again without my consent I am going to use Tor with Google Chromium anyway.https://gitlab.torproject.org/tpo/tpa/team/-/issues/41104Create new alias ac-admins2023-04-13T14:08:44Zmicahmicah@torproject.orgCreate new alias ac-adminsThe anti-censorship team would benefit from an alias that can be used as a sort of 'role' email address for their team. For example, the azure portal for the meek configuration had Sina configured there, and now it has meskio setup there...The anti-censorship team would benefit from an alias that can be used as a sort of 'role' email address for their team. For example, the azure portal for the meek configuration had Sina configured there, and now it has meskio setup there, but it is a bit of a single point of failure, when that could be configured to be `ac-admins@torproject.org` with it pointing to `meskio`, `shelikhoo`, `cohosh` and `micah`.anarcatanarcathttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/81Snowflake is Off / WebRTC feature is not detected.2023-04-23T10:27:21ZcypherpunksSnowflake is Off / WebRTC feature is not detected.I've just installed Snowflake via Chrome and it's not working. Can you confirm the process has been followed correctly? What have I done wrong - or not done at all? Thanks.I've just installed Snowflake via Chrome and it's not working. Can you confirm the process has been followed correctly? What have I done wrong - or not done at all? Thanks.https://gitlab.torproject.org/tpo/core/tor/-/issues/40764Tor dev 4.8 compile error2023-03-09T17:55:14ZredbearTor dev 4.8 compile errorUnder src/core/or/circuituse.c
this is the original **hs_metrics_failed_rdv(&circ->hs_ident->identity_pk,HS_METRICS_ERR_RDV_PATH);** but it gives error cause passing two arguments while should be one.
i changed it to this on...Under src/core/or/circuituse.c
this is the original **hs_metrics_failed_rdv(&circ->hs_ident->identity_pk,HS_METRICS_ERR_RDV_PATH);** but it gives error cause passing two arguments while should be one.
i changed it to this one and the error disappear **hs_metrics_failed_rdv(&circ->hs_ident->identity_pk);**
The thing is located on /src/features/hs/hs_metrics.h
Someone took this error about this one while compile ?gabi-250gabi-250https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/92On M1 macOS, the browser only start if you manually check Rosetta compatibili...2023-02-28T13:05:43ZruihildtOn M1 macOS, the browser only start if you manually check Rosetta compatibility modeIf you install the Mullvad Browser on M! macOS, the following error message appears:
![image](/uploads/7c54ab7aa97fa9ff39fb7ccb63a79d9f/image.png)
To make it work, you need to:
- Right click on the icon in Applications
- Click on Get In...If you install the Mullvad Browser on M! macOS, the following error message appears:
![image](/uploads/7c54ab7aa97fa9ff39fb7ccb63a79d9f/image.png)
To make it work, you need to:
- Right click on the icon in Applications
- Click on Get Info
- In the General section, tick Open using Rosetta
It will then start. Is there a way to make it run automatically in Rosetta compatibility mode?https://gitlab.torproject.org/tpo/tpa/team/-/issues/41076Revoke tor-security@lists.torproject.org OpenPGP key2023-03-06T15:33:04Zmicahmicah@torproject.orgRevoke tor-security@lists.torproject.org OpenPGP keyNow that #41014 resulted in the `tor-security@lists.tpo` alias being removed, it would be good to revoke the `tor-security@lists.tpo` schleuder list key, so people do not continue to try and use it. That key is on the schleuder side, and...Now that #41014 resulted in the `tor-security@lists.tpo` alias being removed, it would be good to revoke the `tor-security@lists.tpo` schleuder list key, so people do not continue to try and use it. That key is on the schleuder side, and I do not have access to it.
It seems there are two users a `torschleuder` user and a `schleuder` user, and the later one is the one who has access to .gnupg.
I asked @dgoulet to see if he was able to revoke it, but he said, he does not have access to that user.anarcatanarcathttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41052can't push account keyring to alberti: detected dubious ownership in repository2023-02-01T19:30:59ZKezcan't push account keyring to alberti: detected dubious ownership in repository```
$ git push alberti
Enumerating objects: 10, done.
Counting objects: 100% (10/10), done.
Delta compression using up to 12 threads
Compressing objects: 100% (7/7), done.
Writing objects: 100% (8/8), 2.89 KiB | 2.89 MiB/s, done.
Total 8...```
$ git push alberti
Enumerating objects: 10, done.
Counting objects: 100% (10/10), done.
Delta compression using up to 12 threads
Compressing objects: 100% (7/7), done.
Writing objects: 100% (8/8), 2.89 KiB | 2.89 MiB/s, done.
Total 8 (delta 4), reused 1 (delta 0), pack-reused 0
remote: + env -i HOME=/home/kez make -C /srv/db.torproject.org/keyrings
remote: make: Entering directory '/srv/db.torproject.org/keyrings'
remote: umask 002 && \
remote: cd keyring && \
remote: git -c safe.directory=/srv/db.torproject.org/keyrings/keyring.git pull && \
remote: rm -f torproject-keyring.gpg && \
remote: ./build-keyring && \
remote: cp -f torproject-*.gpg ..
remote: fatal: detected dubious ownership in repository at '/srv/db.torproject.org/keyrings/keyring'
remote: To add an exception for this directory, call:
remote:
remote: git config --global --add safe.directory /srv/db.torproject.org/keyrings/keyring
remote: make: *** [Makefile:5: torproject-keyring.gpg] Error 128
remote: make: Leaving directory '/srv/db.torproject.org/keyrings'
To alberti.torproject.org:/srv/db.torproject.org/keyrings/keyring.git
598d96a..96a747f master -> master
```
so we have dubious ownership in the account-keyring repo on alberti. i think the only solution is to add it as a safe directory, unless we want to require everyone to push to the alberti remote as the `git` user.
/cc @anarcat @lavamindanarcatanarcathttps://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/62Bad UX when attempting run multiple instances of Mullvad Browser2023-03-22T12:08:18ZrichardBad UX when attempting run multiple instances of Mullvad BrowserSo we disable remote execution (if I recall correctly) which prevents the desktop environment from creating new tabs/windows in an existing process(jump list commands in Windows). However, when we attempt to launch a duplicate instance f...So we disable remote execution (if I recall correctly) which prevents the desktop environment from creating new tabs/windows in an existing process(jump list commands in Windows). However, when we attempt to launch a duplicate instance from the desktop environment we get this dialog which is less than helpful:
![image](/uploads/c840bf2c05481577bbb4cb740e1c1de4/image.png)
We probably want to tweak this to be more accurate useful.
/cc @donutshttps://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/50about:logo shows Firefox logo2023-02-02T14:25:24Zrichardabout:logo shows Firefox logoThis asset needs to be swapped outThis asset needs to be swapped outhttps://gitlab.torproject.org/tpo/network-health/tor-weather/-/issues/21provide setup.py for building distributions2023-02-07T21:25:01ZKezprovide setup.py for building distributionspipenv doesn't provide its own build system, instead requiring a setup.py file to build distributions. a setup.py file can be generated with `pipenv-setup sync`, and will need to have its required fields (package name, version, authors, ...pipenv doesn't provide its own build system, instead requiring a setup.py file to build distributions. a setup.py file can be generated with `pipenv-setup sync`, and will need to have its required fields (package name, version, authors, etc.) manually added.
note: pipenv-setup currently requires an older version of the `vistir` package, which has to be manually installed with `pip install vistir==0.6.1` <https://github.com/Madoshakalaka/pipenv-setup/issues/138>
related: tpo/tpa/team#41034 - i can use the current source to set up the environment on weather-01, but i would prefer to install it as a wheel for the production environmenthttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41592newwin footgun: lock `browser.startup.blankWindow` = true2023-11-16T23:16:37ZThorinnewwin footgun: lock `browser.startup.blankWindow` = true**edge** case?: see AF (arkenfox) https://github.com/arkenfox/user.js/issues/1618 (**long read: ignore if you can**)
tl;dr:
- AF uses RFP which has newwin protections (AF uses 1600 x 900 as maximums: FF has no crowd anyway)
- > ```js
...**edge** case?: see AF (arkenfox) https://github.com/arkenfox/user.js/issues/1618 (**long read: ignore if you can**)
tl;dr:
- AF uses RFP which has newwin protections (AF uses 1600 x 900 as maximums: FF has no crowd anyway)
- > ```js
> /* 4507: disable showing about:blank as soon as possible during startup [FF60+]
> * When default true this no longer masks the RFP chrome resizing activity
> * [1] https://bugzilla.mozilla.org/1448423 ***/
> user_pref("browser.startup.blankWindow", false);
> ```
- the reason for this was cosmetic: hide the (more noticeable on slower machines) delay and resizing etc
A user has reported a case where newwin is not firing (on app start, I did not push for menu>newwin tests). I can't replicate (yet). It doesn't matter what state the browser was closed in (xulstore). It may have something to do with trying to open larger than the screen: the screen is `1536 x 864` (1920 but at system scaling 1.25) and we're opening at `1600 x 900` (both of which are **just** larger than the res available), and this likely makes the OS/app resize to fit the screen - I do not think this is maximized - the decoration for maximze/restore is at odds. AFAICT the user does not use any tile/edge snapping utils.
given TB's settings are `1000 x 1000` and we have users with both width+height lower res than that, perhaps we should lock the pref to true (default) - it's probably not even maintained (it's hidden) and is likely to just be a testing pref during rollout. **The problem is resolved when the pref is at default (true)**
@ma1 for your newwin investigationsThorinThorinhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41041Al needs a login for BTCPayServer2023-02-15T14:55:40Zal smithAl needs a login for BTCPayServerThe body of the ticket is raising questions already answered by the title of the ticket. ;)The body of the ticket is raising questions already answered by the title of the ticket. ;)anarcatanarcathttps://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/41Audit/Look into Mullvad Browser Extension2023-03-01T18:54:09ZrichardAudit/Look into Mullvad Browser Extensionhttps://github.com/mullvad/browser-extensionhttps://github.com/mullvad/browser-extensionma1ma1https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/40Verify WebRTC local IP leaks are no longer occurring in Firefox2023-03-20T13:57:59ZrichardVerify WebRTC local IP leaks are no longer occurring in Firefoxruihildtruihildthttps://gitlab.torproject.org/tpo/core/tor/-/issues/40735[WARN] Tried connecting to router ... identity keys were not as expected2023-11-14T16:59:05Zcypherpunks[WARN] Tried connecting to router ... identity keys were not as expectedBackground: Tor Browser 12.0, Tor 4.7.12, Windows 7, vanilla bridges.
Repeatedly getting the following log line.
```
[WARN] Tried connecting to router at *address* ID=<none> RSA_ID=*FP1*, but RSA + ed25519 identity keys were not as exp...Background: Tor Browser 12.0, Tor 4.7.12, Windows 7, vanilla bridges.
Repeatedly getting the following log line.
```
[WARN] Tried connecting to router at *address* ID=<none> RSA_ID=*FP1*, but RSA + ed25519 identity keys were not as expected: wanted *FP1* + no ed25519 key but got *FP2* + *edFP*.
```
Ideas of what happened:
* MITM
* Bridge operator reinstalled it in-between me getting the bridge and now.
What is wrong:
* Bridge should be marked as unreachable: either it is not used already and connections are doomed to spend resources for nothing, or it should not be used as something is clearly wrong with it
* There should be a way to distinguish first idea from second - my best guess is building a tunneled directory connection to bridge authority and asking "Is there a bridge *FP2* and does it listen on *address*?"https://gitlab.torproject.org/tpo/tpa/team/-/issues/41012Issue with varnish on onionoo-frontends2022-12-20T19:09:13ZHiroIssue with varnish on onionoo-frontendsI have been receiving every few hours alerts from nagios about onionoo backend not updating the index. But I have checked and the service has been running every hour and updating the statuses (summary from the logs pasted below). I wonde...I have been receiving every few hours alerts from nagios about onionoo backend not updating the index. But I have checked and the service has been running every hour and updating the statuses (summary from the logs pasted below). I wonder if we are having some issues with Varnish caching the results?
The nagios check is triggered if at least one index has not been updated for a few hours. @gk has hourly snapshots from onionoo so we can check what has been served in the last few days.
I have checked our configs in puppet and I can't spot anything that would cause an issue. I have also been looking at requests on the frontends and it seems varnish is querying the backend correctly.
```
2022-12-17 00:07:15,827 INFO o.t.m.o.u.StatusUpdateRunner:51 UptimeStatusUpdater
1 hours of relay uptimes processed
1 hours of bridge uptimes processed
8,702 uptime status files updated
--
2022-12-17 01:06:52,137 INFO o.t.m.o.u.StatusUpdateRunner:51 UptimeStatusUpdater
1 hours of relay uptimes processed
1 hours of bridge uptimes processed
8,692 uptime status files updated
--
2022-12-17 02:07:26,965 INFO o.t.m.o.u.StatusUpdateRunner:51 UptimeStatusUpdater
1 hours of relay uptimes processed
1 hours of bridge uptimes processed
8,739 uptime status files updated
--
2022-12-17 03:06:36,807 INFO o.t.m.o.u.StatusUpdateRunner:51 UptimeStatusUpdater
1 hours of relay uptimes processed
0 hours of bridge uptimes processed
6,109 uptime status files updated
--
2022-12-17 04:08:06,285 INFO o.t.m.o.u.StatusUpdateRunner:51 UptimeStatusUpdater
2 hours of relay uptimes processed
2 hours of bridge uptimes processed
8,765 uptime status files updated
--
2022-12-17 05:07:02,203 INFO o.t.m.o.u.StatusUpdateRunner:51 UptimeStatusUpdater
1 hours of relay uptimes processed
1 hours of bridge uptimes processed
8,698 uptime status files updated
--
2022-12-17 06:06:34,321 INFO o.t.m.o.u.StatusUpdateRunner:51 UptimeStatusUpdater
1 hours of relay uptimes processed
1 hours of bridge uptimes processed
8,697 uptime status files updated
--
2022-12-17 07:06:29,204 INFO o.t.m.o.u.StatusUpdateRunner:51 UptimeStatusUpdater
1 hours of relay uptimes processed
1 hours of bridge uptimes processed
8,715 uptime status files updated
--
2022-12-17 08:07:45,006 INFO o.t.m.o.u.StatusUpdateRunner:51 UptimeStatusUpdater
1 hours of relay uptimes processed
1 hours of bridge uptimes processed
8,706 uptime status files updated
--
2022-12-17 09:06:27,389 INFO o.t.m.o.u.StatusUpdateRunner:51 UptimeStatusUpdater
1 hours of relay uptimes processed
0 hours of bridge uptimes processed
6,083 uptime status files updated
--
2022-12-17 10:06:39,656 INFO o.t.m.o.u.StatusUpdateRunner:51 UptimeStatusUpdater
1 hours of relay uptimes processed
2 hours of bridge uptimes processed
8,697 uptime status files updated
--
2022-12-17 11:07:11,588 INFO o.t.m.o.u.StatusUpdateRunner:51 UptimeStatusUpdater
1 hours of relay uptimes processed
1 hours of bridge uptimes processed
8,702 uptime status files updated
--
2022-12-17 12:07:09,905 INFO o.t.m.o.u.StatusUpdateRunner:51 UptimeStatusUpdater
1 hours of relay uptimes processed
1 hours of bridge uptimes processed
8,705 uptime status files updated
--
2022-12-17 13:06:34,323 INFO o.t.m.o.u.StatusUpdateRunner:51 UptimeStatusUpdater
1 hours of relay uptimes processed
1 hours of bridge uptimes processed
8,671 uptime status files updated
--
2022-12-17 14:06:47,110 INFO o.t.m.o.u.StatusUpdateRunner:51 UptimeStatusUpdater
1 hours of relay uptimes processed
1 hours of bridge uptimes processed
8,688 uptime status files updated
--
2022-12-17 15:07:03,315 INFO o.t.m.o.u.StatusUpdateRunner:51 UptimeStatusUpdater
1 hours of relay uptimes processed
0 hours of bridge uptimes processed
6,086 uptime status files updated
--
2022-12-17 16:06:42,723 INFO o.t.m.o.u.StatusUpdateRunner:51 UptimeStatusUpdater
1 hours of relay uptimes processed
2 hours of bridge uptimes processed
8,696 uptime status files updated
```anarcatanarcathttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41530Tor Browser 12.0 update duplicated top "~/.torbrowser" folder; caused icon issue2023-01-31T20:36:12ZjbluesTor Browser 12.0 update duplicated top "~/.torbrowser" folder; caused icon issueUsing Linux Mint 20.1 Cinnamon
Not sure if this was a bug or if anyone besides me saw the problem.
I've used same top level .torbrowser folder (in Home) for all TBB updates for couple years.
Never a problem updating in the existing .torb...Using Linux Mint 20.1 Cinnamon
Not sure if this was a bug or if anyone besides me saw the problem.
I've used same top level .torbrowser folder (in Home) for all TBB updates for couple years.
Never a problem updating in the existing .torbrowser folder & no problem with its panel icon.
After updating to 12.0, the panel icon for TBB was some Firefox - not the purple bullseye.
Always have used updates setting: "Check for updates but let you choose to install them."
TBB automatically notified of an update (12.0). I clicked the update button. It downloaded OK & prompted to restart("click here"). Started back up - showing a Firefox icon, not a purple bullseye.
Looked at **start-tor-browser.desktop** - for Icon it had:
`Icon=web-browser`
I didn't realize why that (apparently) changed. Quick / temp fix, just entered the correct path to TBB default icons. Worked until update 12.0.1 - again TBB showed a Firefox icon on the panel.
Realized the 12.0 update had added a duplicate ".torbrowser" folder. I did zero activity in any of TBB's folders before or after the 12.0 update caused the icon switch. Very unlikely I caused this problem.
It now showed **~/.torbrowser/_.torbrowser_/tor-browser_en-US/Browser**...
TBB still started & ran OK, but icon kept changing. After eliminating the 2nd ".torbrowser" folder, the panel icon is fine & the desktop file self corrected the Icon= path.https://gitlab.torproject.org/tpo/tpa/team/-/issues/41001Out of memory on colchicifolium2022-12-20T19:08:55ZHiroOut of memory on colchicifoliumI am getting "out of memory" errors on colchicifolium. It seems like collector is using all the memory (https://grafana1.torproject.org/d/Z7T7Cfemz/node-exporter-full?orgId=1&var-job=node&var-node=colchicifolium.torproject.org&var-port=9...I am getting "out of memory" errors on colchicifolium. It seems like collector is using all the memory (https://grafana1.torproject.org/d/Z7T7Cfemz/node-exporter-full?orgId=1&var-job=node&var-node=colchicifolium.torproject.org&var-port=9100).
Would it be possible to add more ram to this VM?Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40994Request for limited root access on gitlab-dev as per TPA-RFC072023-01-02T02:36:40Zmicahmicah@torproject.orgRequest for limited root access on gitlab-dev as per TPA-RFC07```
As detailed in [TPA-RFC-7](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-7-root), I am hereby requesting time-limited root access to the gitlab-dev server in order to test the patch work necessary for tpo/tpa/gitl...```
As detailed in [TPA-RFC-7](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-7-root), I am hereby requesting time-limited root access to the gitlab-dev server in order to test the patch work necessary for tpo/tpa/gitlab#23.
I currently have (sudo) git access to perform actions there, however I will need to do a few things as root in order to accomplish this quest:
. disable puppet on the system so it wont enforce a state that I would modify as detailed below (requires root)
. configure gitlab email sending to test the patch (requires editing /etc/gitlab/gitlab.rb as root)
. disable email sending on the server to keep the server from sending confusing and incorrect notifications to users (requires root)
. be able to process the unsent mail in order to determine if the patch has properly worked (requires root)
. remove any queued mails that would be sent out by gitlab that should not be sent (requires root)
All of the above I could coordinate with TPA folks and ask them to do them when I get to those stages, but due to the limited time windows I have to do the work, having this access (temporarily) would facilitate a much speedier result.
-----BEGIN PGP MESSAGE-----
owFtVE2o3FQUTmtFDNS6kAdikfN4CDMyydh5v3bVeT+Fh1KK6Kr+cJOcTG4nuSe9
9+aFgAVX/nTVhS5cuBMEV/pAwYV00YWgiG7cVFy4EEXQre2qnpvMvE6tAwMhnHO+
n/OdXD/5kOcvBQP85dCe/+3Yd39GXnz9swtjAwlaIXNMQCq49PLFcfDS+Z1g87Ve
Zm1pzg6HE2lzEYWWdKnpMsY2JD0Z2pL4L4YWRTEMhrWcSjMsKZdx494HOo2DzUAT
2f4A9kEUkKHGqAGNVyo0VqoJWFlgkMtCWkZ3pSDiGI0BS2AzhA45SPAADOoD1I4i
6YQfXAVPactKYeMMatJTUOj6hW4gJS6acezmrIxWQ/D9fYgrrVHZvIFMHCD0TJVQ
34EtwJeoeULBb6wkZRyOxgFkVKPjsQ+1zHOGY+JcnRAISLHmMtZlQJhOziJdnk1F
mUuTuSoDrQtnfT+ERBoR5ayjKku0QKpVZRpjsQBDwMRqUhZQMaUYGcpYYZGrhHVM
qMoTKCiRaeOQj/YZYU419JzhUmNHqc94MalUTio9Nxiw4Aa2WCXtVh6w9t4ITGS7
uSHaeGbrPB86msvuL2i6f/RcWrdMBpoilouvUk3FUbXjWRn3JJRLZ0y8t9iCIitT
GYvZZggq7jb/IzRirxwJt09N3WoZq1KMYKFltrghNg51IRWCTBfUZyyL2zkRnBiX
Mrb2QSyNBXGYhGrcZiuucfNNt6RuRZGTycBUWeBDmJnfFpisrWBlR1X/hfDHHDjq
iInIYXGS266YWIJULhK1tBnwDXP886lpfRNm6nqKWU7bxzpD9RH3Tzhu7a2RQReq
CZoBREwvqXB+hPP7dMfK81VCteHW9nSORra+DNzLNkEu37Nb6nGIS9JCy7zpz4xI
RSxz2WZYQFGxx6bkS5K8BtZb5Tb03/3phLfke1eXlk9cu3zt5vLfr3554fiTX8y/
Xw8f54/XxTeeeMvjX+j1pDEV6iAt9Tn2sEtGyCtT5aQMU5naLCNtOIwqVGi3xhvj
rfHO6ujM3t76zvbG2t5zozPPb6+Pdkc7G+u7u9ujzbW1jb11z3/08TnicnHM+7H5
5IUPN39/+4OlWy8mf/y89a344dMbTz9y2//rmYOVlf2vvLtv/tM71z/1/uvfvHfp
xlN3qmc/vrl66pXDdz4//PXW6enX3z/2Lw==
=eyB2
-----END PGP MESSAGE-----
```