The Patch that converts a Firefox to a Tor Browser

Have you ever wondered was makes the Tor Browser the Tor Browser? That is, what patch you would have to apply to Firefox in order to end up with a Tor Browser.

The answer is not really easy to get. I expected to do something like git clone tor-browser ; git diff firefox-upstream or so. But for an odd reason, the Tor Browser people do not import the pristine Firefox version to their repository. As a side note, the build instructions are a bit arcane. I was hoping for such an important tool to be built easily. But it requires root access and a wild container technology. Weird. In fact, this is preventing me from flatpaking the Tor Browser right now. But I’m working on it.

Long story story, to get the diff, do something like:

wget releases.mozilla.org/pub/firefox/releases/60.2.1esr/source/firefox-60.2.1esr.source.tar.xz
git clone  https://git.torproject.org/tor-browser.git
cd tor-browser
git checkout --orphan firefox
tar --extract --strip-components=1 --file ../firefox-60.2.1esr.source.tar.xz 
git add .
git commit -m 'firefox upstream import'

git diff firefox...tor-browser-60.2.1esr-8.5-1-build1

Of course, you need to adjust the Firefox and the Tor Browser version in the future. I have imported the upstream firefox code into this repository so that you can make diffs as you like. Unfortunately, the Github Web interface does not show diffs of unrelated branches.

Talking at PETCon2018 in Hamburg, Germany and OpenPGP Email Summit in Brussels, Belgium

Just like last year, I managed to be invited to the Privacy Enhancing Technologies Conference to talk about GNOME. First, Simone Fischer-Huebner from Karlstadt University talked about her projects which are on the edge of security, cryptography, and usability, which I find a fascinating area to be in. She presented outcomes of her Prismacloud project which also involves fancy youtube videos…

I got to talk about how I believe GNOME is in a good position make a safe and secure operating system. I presented some case studies and reported on the challenges that I see. For example, Simone mentioned in her talk that certain users don’t trust a software if it is too simple. Security stuff must be hard, right?! So how do measure the success of your security solution? Obviously you can test with users, but certain things are just very hard to get users for. For example, testing GNOME Keysign requires a user not only with a set up MUA but also with a configured GnuPG. This is not easy to come by. The discussions were fruitful and I got sent a few references that might be useful in determining a way forward.

OpenPGP Email Summit

I also attended the OpenPGP Email Summit in Brussels a few weeks ago. It’s been a tiny event graciously hosted by a local company. Others have written reports, too, which are highly interesting to read.

It’s been an intense weekend with lots of chatting, thinking, and discussing. The sessions were organised in a bar-camp style manner. That is, someone proposed what to discuss about and the interested parties then came together. My interest was in visual security indication, as triggered by this story. Unfortunately, I was lured away by another interesting session about keyserver and GDPR compliance which ran in parallel.

For the plenary session, Holger Krekel reported on the current state of Delta.Chat. If you haven’t tried it yet, give it a go. It’s trying to provide an instant messaging interface with an email transport. I’ve used this for a while now and my experience is mixed. I still get to occasional email I cannot decrypt and interop with my other MUA listening on the very same mailbox is hit and miss. Sometimes, the other MUA snatches the email before Delta.chat sees it, I think. Otherwise, I like the idea very much. Oh, and of course, it implements Autocrypt, so your clients automatically encrypt the messages.

Continuing the previous talk, Azul went on to talk about countermitm, an attempt to overcome Autocrypt 1.0‘s weaknesses. This is important work. Because without the vision of how to go from Autocrypt Level 1 to Level 2, you may very well question to usefulness. As of now, Emails are encrypted along their way (well. Assuming MTA-STS) and if you care about not storing plain text messages in your mailbox, you could encrypt them already now. Defending against active attackers is hard so having sort of a plan is great. Anyway, countermitm defines “verified groups” which involves a protocol to be run via Email. I think I’ve mentioned earlier that I still think that it’s a bit a sad that we don’t have the necessary interfaces to run protocols over Email. Outlook, I think, can do simple stuff like voting for of many options or retracting an email. I would want my key exchange to be automated further, i.e. when GNOME Keysign sends the encrypted signature, I would want the recipient to decrypt it and send it back.

Phil Zimmermann, the father of PGP, mentioned a few issues he sees with the spec, although he also said that it’s been a while that he was deeply into this matter. He wanted the spec to be more modern and more aggressively pushing for today’s cryptography rather than for the crypto of the past. And in fact, he wants the crypto of tomorrow. Now. He said that we know that big agencies are storing message today for later analyses. And we currently have no good way of having what people call “perfect forward secrecy” so a future key compromise makes the messages of today readable. He wants post quantum crypto to defeat the prying eyes. I wonder whether anybody has implemented pq-schemes for GnuPG, or any other OpenPGP implementation, yet.

My takeaways are: The keyserver network needs a replacement. Currently, it is used for initial key discovery, key updates, and revocations. I think we can solve some of these problems better if we separate them. For example, revocations are pretty much a fire and forget thing whereas other key updates are not necessarily interesting in twenty years from now. Many approaches for making initial key discovery work have been proposed. WKD, Autocrypt, DANE, Keybase, etc. Eventually one of these approaches wins the race. If not, we can still resort back to a (plain) list of Email addresses and their key ids. That’s as good or bad as the current situation. For updates, the situation is maybe not as bad. But we might still want to investigate how to prevent equivocation.

Another big thing was deprecating cruft in the spec to move a bit faster in terms of cryptography and to allow implementers to get a compliant program running (more) quickly. Smaller topics were the use of PQ safe algorithm and exploitation of backwards incompatible changes to the spec, i.e. v5 keys with full fingerprints. Interestingly enough, a trimmed down spec had already been developed here.

Speaking at FIfFKon 18 in Berlin, Germany

I was invited to be a panellist at this year’s FIfFKon in Berlin, Germany. While I said hi to the people at All Systems Go!, my main objective in Berlin was to attend the annual conference of the FIfF, the association for people in computing caring about peace and social responsibility.

The most interesting talk for me was held by Rainer Mühlhoff on the incapacitation if the user. The claim, very broadly speaking, is that providing a usable interface prevents your users from learning how to operate the machine properly. Or in other words: Making an interface for dumb people will attract dumb people and not make them smarter. Of course, he was more elaborate than that.

He presented Android P which nudges the user into a certain behaviour. In Android, you get to see for how long you have used an app and encourages you to stop. Likewise, Google nudges you into providing your phone number for account recovery. The design of that dialogue makes it hard to hit the button to proceed without providing the number. Those nudges do not prevent a choice to be made, they just make it more likely that the user makes one particular choice. The techniques are borrowed from public policy making and commercial settings. So the users are being an instrument themselves rather than a sovereign entity.

Half way through his talk he made a bit of a switch to “sealed interfaces” and presented the user interface of a vacuum cleaner. In the beginning, the nozzle had a “bristly” or “flat” setting, depending on whether you wanted to use it on a carpet or a flat surface. Nowadays, the pictogram does not show the nozzle any more, but rather the surface you want to operate on. Similarly, microwave ovens do not show the two levers for wattage and time any more, but rather full recipes like pizza, curry, or fish.
The user is prevented from understanding the device in its mechanical details and use it as an instrument based on what it does. Instead the interaction is centred on the end purpose rather than using the device as a tool to achieve this end. The commercialisation of products numbs people down in their thinking. We are going from “Don’t make me think” to “Can you do the thinking for me” as, he said, we can see with the newer Android interfaces which tries to know already what you intend to do.

Eventually, you adapt the technology to the human rather than adapting the human to the technology. And while this is correct, he says, and it has gotten us very far, it is wrong from a social theory point of view. Mainly because it suggests that it’s a one-way process whereas it really is an interdependency. Because the interaction with technology forms habits and coins how the user experiences the machine. Imagine, he said, to get a 2018 smartphone in 1995. Back in the day, you probably could not have made sense out of it. The industrial user experience design is a product of numbing users down.

A highly interesting talk that got me thinking a little whether we ought to teach the user the inner workings of software systems.

The panel I was invited for had the topic “More privacy for smart phones – will the GDPR get us a new break through?” and we were discussing with a corporate representative and other people working in data protection. I was there in my capacity as a Free Software representative and as someone who was working on privacy enhancing technologies. I used my opportunities to praise Free Software and claim that many problems we were discussion would not exist if we consequently used Free Software. The audience was quite engaged and asked a lot of questions. Including the ever popular point of *having* to use WhatsApp, Signal, or any of those proprietary products, because of the network effect and they demanded more regulation. I cautioned that call for various reasons and mentioned that the freedom to choose the software to run has not yet fully been exploited. Afterwards, some projects presented themselves. It was an interesting mix of academic and actual project work. The list is on the conference page.

Talking at OSDNConf in Kyiv, Ukraine

I was fortunate enough to be invited to Kyiv to keynote (video) the local Open Source Developer Network conference. Actually, I had two presentations. The opening keynote was on building a more secure operating system with fewer active security measures. I presented a few case studies why I believe that GNOME is well positioned to deliver a nice and secure user experience. The second talk was on PrivacyScore and how I believe that it makes the world a little bit better by making security and privacy properties of Web sites transparent.

The audience was super engaged which made it very nice to be on stage. The questions, also in the hallway track, were surprisingly technical. In fact, most of the conference was around Kernel stuff. At least in the English speaking track. There is certainly a lot of potential for Free Software communities. I hope we can recruit these excellent people for writing Free Software.

Lennart eventually talked about CAsync and how you can use that to ship your images. I’m especially interested in the cryptography involved to defend against certain attacks. We also talked about how to protect the integrity of the files on the offline disk, e.g. when your machine is off and some can access the (encrypted) drive. Currently, LUKS does not use authenticated encryption which makes it possible that an attacker can flip some bits in the disk image you read.

Canonical’s Christian Brauner talked about mounting in user namespaces which, historically, seemed to have been a contentious topic. I found that interesting, because I think we currently have a problem: Filesystem drivers are not meant for dealing with maliciously crafted images. Let that sink for a moment. Your kernel cannot deal with arbitrary data on the pen drive you’ve found on the street and are now inserting into your system. So yeah, I think we should work on allowing for insertion of random images without having to risk a crash of the system. One approach might be libguestfs, but launching a full VM every time might be a bit too much. Also you might somehow want to promote drives as being trusted enough to get the benefit of higher bandwidth and lower latency. So yeah, so much work left to be done. ouf.

Then, Tycho Andersen talked about forwarding syscalls to userspace. Pretty exciting and potentially related to the disk image problem mentioned above. His opening example was the loading of a kernel module from within a container. This is scary, of course, and you shouldn’t be able to do it. But you may very well want that if you have to deal with (proprietary) legacy code like Cisco, his employer, does. Eventually, they provide a special seccomp filter which forwards all the syscall details back to userspace.

As I’ve already mentioned, the conference was highly technical and kernel focussed. That’s very good, because I could have enlightening discussions which hopefully get me forward in solving a few of my problems. Another one of those I was able to discuss with Jakob on the days around the conference which involves the capabilities of USB keyboards. Eventually, you wouldn’t want your machine to be hijacked by a malicious security device like the Yubikey. I have some idea there involving modifying the USB descriptor to remove the capabilities of sending funny keys. Stay tuned.

Anyway, we’ve visited the city and the country before and after the event and it’s certainly worth a visit. I was especially surprised by the coffee that was readily available in high quality and large quantities.

GNOME Keysign 0.9.9

tl;dr: We have a new Keysign release with support for exchanging keys via the Internet.

I am very proud to announce this version of GNOME Keysign, because it marks an important step towards a famous “1.0”. In fact, it might be just that. But given the potentially complicated new dependencies, I thought it’d be nice to make sort of an rc release.

The main feature is a transport via the Internet. In fact, the code has been lurking around since last summer thanks to Ludovico’s great work. I felt it needed some massaging and more gentle introduction to the code base before finally enabling it.

For the transport we use Magic Wormhole, an amazing package for transferring files securely. If you don’t know it yet, give it a try. It is a very convenient tool for sending files across the Internet. They have a rendezvous server so that it works in NATted environments, too. Great.

You may wonder why we need an Internet transport, given that we have local network and Bluetooth already. And the question is good, because initially I didn’t think that we’d expose ourselves to the Internet. Simply because the attack surface is just so much larger and also because I think that it’s so weird to go all the way through the Internet when all we need is to transfer a few bytes between two physically close machines. It doesn’t sound very clever to connect to the Internet when all we need is to bridge 20 centimetres.

Anyway, as it turns out, WiFi access points don’t allow clients to connect to each other :( Then we have Bluetooth, but it’s still a bit awkward to use. My impression is that people are not satisfied with the quality of Bluetooth connections. Also, the Internet is comparatively easy to use, both as a programmer and a user.

Of course, we now also have the option to exchange keys when not being physically close. I do not recommend that, though, because our security assumes the visual channel to be present and, in fact, secure. In other words: Scan the barcode for a secure key signing experience. Be aware that if you transfer the “security code” manually via other means, you may be compromised.

With this change, the UX changes a bit for the non-Internet transports, too. For example, we have a final page now which indicates success or failure. We can use this as a base for accompanying the signing process further, e.g. sign the key again with a non-exportable short-term signature s.t. the user can send an email right away. Or exchange the keys again after the email has been received. Exciting times ahead.

Now, after the wall of text, you may wonder how to get hold of this release. It should show up on Flathub soon.

Talking at GUADEC 2018 in Almería, Spain

I’ve more or less just returned from this year’s GUADEC in Almeria, Spain where I got to talk about assessing and improving the security of our apps. My main point was to make people use ASan, which I think Michael liked ;) Secondarily, I wanted to raise awareness for the security sensitivity of some seemingly minor bugs and how the importance of getting fixes out to the user should outweigh blame shifting games.

I presented a three-staged approach to assess and improve the security of your app: Compilation time, Runtime, and Fuzzing. First, you use some hardening flags to compile your app. Then you can use amazing tools such as ASan or Valgrind. Finally, you can combine this with afl to find bugs in your code. Bonus points if you do that as part of your CI.

I encountered a few problems, when going that route with Flatpak. For example, the libasan.so is not in the Platform image, so you have to use an extension to have it loaded. It’s better than it used to be, though. I tried to compile loads of apps with ASan in the past and I needed to compile a custom GCC. And then mind the circular dependencies, e.g. libmfpr is needed by GCC. If I then compile a libmfpr with ASan, then GCC would stop working, because gcc itself is not linked against ASan. It seems silly to have those annoyances in the stack. And it is. I hope that by making people play around with these technologies a bit more, we can get to a point where we do not have to catch those time consuming bugs.

Panorama in Frigiliana

The organisation around the presentation was a bit confusing as the projector didn’t work for the first ten minutes. And it was a bit unclear who was responsible for making it work. In that room the audio also used to be wonky. I hope it went well alright after all.

GNOME Keysign 0.9.8 released

It’s been a while after my last post. This time, we have many exciting news to share. For one, we have a new release of GNOME Keysign which fixes a few bugs here and there as well as introduces Bluetooth support. That is, you can transfer your key with your buddy via Bluetooth and don’t need a network connection. In fact, it becomes more and more popular for WiFis to block clients talking to each other. A design goal is (or rather: was, see down below) to not require an Internet connection, simply because it opens up a can of worms with potential failures and attacks. Now you can transfer the key even if your WiFi doesn’t let you communicate with the other machine. Of course, both of you need have to have Bluetooth hardware and have it enabled.

The other exciting news is the app being on Flathub. Now it’s easier than ever to install the app. Simply go to Flathub and install it from there. This is a big step towards getting the app into users’ hands. And the sandbox makes the app a bit more trustworthy, I hope.


flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
flatpak install flathub org.gnome.Keysign

The future brings cool changes. We have already patches lined up that bring an Internet transport with the app. Yeah, that’s contrary to what I’ve just said a few paragraphs above. And it does cause some issues in the UI, because we do not necessarily want the user to use the Internet if the local transport just works. But that “if” is unfortunately getting bigger and bigger. So I’m happy to have a mix of transports now. I’m wondering what the best way is to expose that information to the user, though. Do we add a button for the potentially privacy invading act of connecting to the Internet? If we do, then why do we not offer buttons for the other transports like Bluetooth or the local network?

Anyway, stay tuned for future updates.

Talking at GPN 2018 in Karlsruhe, Germany

Similar to last year I managed to attend the Gulasch Programmier-Nacht (GPN) in Karlsruhe, Germany. Not only did I attend, I also managed to squeeze in a talk about PrivacyScore. We got the prime time slot on the opening day along with all the other relevant talks, including the Eurovision Song Contest, so we were not overly surprised that the audience had a hard time deciding where to go and eventually decided to attend talks which were not recorded. Our talk was recorded and is available here.

Given the tough selection of the audience by the other talks, we had the people who were really interested. And that showed during the official Q&A as well as in the hallway track. We exchanged contacts with other interested parties and got a few excellent comments on the project.

Another excellent part of this year’s GPN was the exhibition in the museum. As GPN takes places in a joint building belonging to the local media university as well as the superb art and media museum, the proximity to the artsy things allows for an interesting combination. This year, the open codes exhibition was not hosted in the ZKM, but GPN also took place in that exhibition. A fantastic setup. Especially with the GPN’s motto being “digital naïves”. One of the exhibition’s pieces is an assembly robot’s hand doing nothing else but writing a manifesto. Much like a disciplinary action for a school child. Except that the robot doesn’t care so much. Yet, it’s usefulness only expands to writing these manifestos. And the robot doesn’t learn anything from it. I like this piece, because it makes me think about the actions we take hoping that they have a desired effect on something or someone but we actually don’t know whether this is indeed the case.

I also like the Critical Engineering Manifesto being exhibited. I like to think about how the people who actual implement cetain technologies can be held responsible for the effects of it on individuals or the society. Especially with more and more “IoT” deployments where the “S” represents their security. It’s easy to blame Facebook for “leaking” user profiles although it’s in their Terms of Services, but it’s harder to shift the blame for the smart milk sensor in your fridge invading my privacy by reporting how much I consume. We will have interesting times ahead of us.

An exhibit pointing out the beauty of algorithms and computation is a board that renders a Julia Set. That’s wouldn’t be so impressive in itself, but you can watch the machine actually compute the values. The exhibit has a user controllable speed regulator and an insight into the CPU as well as the higher level code. I think it’s just an ingenious idea to enable the user to go full speed and see the captivating movements of the beautiful Julia set while also allowing the go super slow to investigate how this beauty is composed of relatively simple operations. Also, the slow execution itself is relatively boring. We get to see that we have to go very fast in order to be entertained. So fast that we cannot really comprehend what is going on.

I whole heartedly recommend visiting this exhibition. And the GPN, of course, too. It’s a nice chaotic event with a particular flair. It’s getting more and more crowded though, so better while the feeling lasts and doesn’t get drowned by all the tourists.

Talking on PrivacyScore at DFN Security Conference 2018 in Hamburg, Germany

I seem to have skipped last year, but otherwise I have been to the DFN Workshop regularly. While I had a publication at this venue before, it’s only this year that I got to have a the conference.

I cannot comment on the other talks so much, because I could not attend too many :( But our talk (slides) was well visited and I think people appreciated the presentation being a bit lighter than the previous one about the upcoming GDPR.

I talked about PrivacyScore.org and how we’ve measured German universities. The paper is here. Our results were mixed. As for TLS deployment, with a lot of imagination we can see a line dividing Germany. The West seems to have fewer problems with their TLS deployment than the East. The more red an area is, the worse its TLS support is. That ranges from not offering TLS at all to having an invalid certificate or using broken parameters.

As for tracking its users we had the hypothesis that privately run institutions have a higher interest in tracking its users than publicly run institutions. The following graphic reflects the geographic distribution of trackers on German university’s Web sites.
That hypothesis can be confirmed by looking at the PrivacyScore list that discriminates those institutions.

We found data that was very likely not meant to be there, such as database dumps or Git repositories of the Web site’s code (including passwords for their staging environments, etc.). We tried to report these issues to the Web site operators, but it was difficult to get hold of the responsible people. For the 21 leaks we found I have 93 emails in my mailbox. Ideally, the 21 I sent off were enough. But even sending those emails is hard, because people don’t respect RFC 2142 and have a security@ address. Eventually, we made the Internet a tiny bit more secure by having those Website operators remove the leaks from their Web site, but there are still some pages which have (supposedly) unwanted information such as their visitors’ IP addresses online. The graph below shows that most of the operators who reacted did so in the first few days. So management of security incidents seems to be an area of improvement.

I hope to be able to return next year, if only for the catering ;-) Then, I better attend some more talks and chat with the other guests.

New OpenPGP key

PSA: I’ve rolled over my OpenPGP Key.

The old key F289F7BA977DF4143AE9FDFBF70A02906C301813 is considered to be too short by some and it’s sufficiently old to retire it.

My new key is F98D03D7DC630399AAA6F43826B3F39189C397F6.

It’s been a while since I did that last. And GnuPG still makes it hard to use an expired key, I cannot sign this transition statement with both keys as suggested by this document. Also, I might consider using a service such as https://www.expirybot.com/ for telling me when it’s time to think of a strategy for the next roll-over. It’s a shame we don’t have such tooling in place for the desktop.

Anyway, feel free to grab the new from the WebPKI protected resource here.

sec   dsa1024 2008-12-03 [SC] [expired: 2018-02-28]
      F289F7BA977DF4143AE9FDFBF70A02906C301813
uid           [ expired] Tobias Mueller 

sec   dsa3072 2018-03-17 [SC] [expires: 2023-03-16]
      F98D03D7DC630399AAA6F43826B3F39189C397F6
uid           [ultimate] Tobias Mueller 
ssb   elg3072 2018-03-17 [E] [expires: 2023-03-16]

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQGiBEk21OkRBAC5XDJFPbA2WhhvbKdu51ZOL3iPwMPSp8k1U5qEY0uChuI5eekL
VUHhsQJP+mNSwPMKJuyAZgMtdeG+YHEo06Rh9beOxCRtR1Y4Jzl1iP2jslHUu/r9
O0DLXUOdbsi0oSfNGJt4nxdZheIr/eH18w8Sp/P1l3YooRcyC3wa/lwR2wCgps+U
nBLN5JbQaz4NeoDXROhwDNkD/0mPTNX7WyPWJoEpFwSSKD1ZPaF46fFDhlK6pdyv
120TYoRAtQBYew3XkiW+ZoW4OZiqVJLTqqI8bADSeZ4AaJEgRyKb99tRrpyWFhpk
vMoxtfw2qXDGidcsaeJfqzSw3+qjfjQJMGEkADW5+7d8URTU2I4GURoUUNVYRr+O
lVdUA/4qdHe2E5pkYXlQZAuq8DjUqvqKtay7uCCMFv0NZtXWNn+sPTq108tMfoQ9
QdS74NlbS4Hh/ttMzTZi1z7AEI4Kf74qY77xBjyhPFPSyThxPRH8WjRQLqrZHe0I
G1MtoEFeRfixqCCDtQyTrhQomEgYgSx7phQUTMrCP3wC8uTB6LQkVG9iaWFzIE11
ZWxsZXIgPHRvYmlhc211ZUBnbm9tZS5vcmc+iGYEExECACYCGwMGCwkIBwMCBBUC
CAMEFgIDAQIeAQIXgAUCVtxYfQUJEV+2xwAKCRD3CgKQbDAYE+7uAJ9KEPe5Qqmb
uQBQND8lL89kjBaHZQCeL4lji4/Pxu1wZK+2M1HgXh9dvNK5BA0ESTbU6RAQAK2Q
cpYuL/ieNSzVcXOCLzPMs+jL+nx7GLINoRdTZkK1394bPu4ZUrcUfsfE/Ehm1209
kzD4kXSqbtMCZ0QLo5Ohvzq/TS/d+5kavYiVs0V9UCnjdu0zl/MHjOZ3aghvGKJo
YB+eQNIVoCTLmZIWSE3tHdy+ocoRCPYXLOLZJgewkRmtfOrfg9n+YisLwVryDO4V
kzNZGe+lXf8JKbEXXnL55g+P6gkfDp6IRPm8QetJQ7j6o7xzFGDA+0oJLHc2NgMV
QdZAVZuZwOUJtHkv+HuH88b2mUBAkVLUv1pgyEjEqV45I+OiFdcy9BluzTtXMw00
3oovmmHTLCOars/GGK+tBS6uFMNX59V2lb0QycLwzg6lnedShvl0ivr//khZ2kJ1
avyInTGUdMy5CGM4YB84X8p63EbhrapkM3JmqlZrR71t5GM4nk3IumGCZY1LzO/7
mVbegtYvBc6vcYJqPjwPSLlBdcquQjD49I2UlDI5EfO91rEwkpvVo9RKigKes4yZ
kEP4bzOaXbMrNYuC3ssrbS/zH9w+TPlMSW1w97D2V5mTHsjbaGEgjzPZY3zWklrq
RnHlGEThTsHL0OsdQ0OI7cWUiZn2fMqGSofdeqFAf/o2IAlHGcyAK6MCRNR802dC
8M5XDh1d67QDA2lWL/axMjqgxHKwIR/ufU4EDlTzAAMFEACYnYVIjmfG2eitMowG
21GhIbAyyKjj+xBWeCjB1BVw3ir04fw5I/xaEd5VP3NTY+yv7TZWPdf3myN1SbhT
xeu0YVyzEDs7y2ekpDe6YNiTSRAOoWeb1YObiY6UGTa/vvHtK++Kx+wq7hbdaCaK
AUW2NZ8T9M8p/wX0jxx+CyV/iIfJuhdl9Q08bqRdlnWH+zfHaxq1syUQBMVPVrU/
Gi+IOwo6qcQiW5BI9mZ9WRLQKE5gbvlbzLL49TKcFRq4bCnQXtj6gVCYUIT+wm7I
aNYXl3NcWNWL6GkmuvSxfoF8z/R5Iw+4LUlngSYscXE9c+rFVzp9gfOOqlCbyFRx
1WCHtyLhZfzZub2MmJHQ0+MuYbcP4bG7rGq2QqpYpKYTuqVhhHx8S2EpOOTlx0ys
vLbbGoRdF29i6L4UFl6Tfy1j2S+FSAmug/iv7KbYj4FVeGBh1Rrt+cF//sUXBO6p
OefLSbXRMt7kZNnIyhNfWrM62n03R2nKucTE8oLlFrwZtZ+VTQZicirvwMsC965a
3a3YSX5VD8Ix3/+nYsDeTC8QUTWgK3wmth3gLy1I6ElU5yiSUHMfbFwmI4RFVh5b
fDnoompIAiINvM6KXSxwFfQ1Zwwkxw0iOx7rQ2F/HgTTpXkVA5bISCPChkfIp/WF
S9L5aiwvjo8rXPhb2ChWm1GvpIhPBBgRAgAPAhsMBQJW3FiZBQkRX7bHAAoJEPcK
ApBsMBgTjcIAoJG4JYCcs0RtH8/khWE1nxZzfhgqAJ9DTOJGHUNVqVBg+GtULiuY
wE7HxpkErgRarZOvEQwAnl8+RVZd1Ly24jGPGPW+P57ASaYlwGMj0ifQTvVAfKOE
NCQjcW7njMywLbhFOgDUpR0OfCiK/TJBqLXIa1G2KN2yMQfCCJdrL6bOTT1catMK
vTw9yTjiRnguk6HbM0IuQSbIlTNsLPwUGDQ1NMe3KckcRuLEjdTpubBTRtpYDM50
4Uexua5DS99MTuc+Mgm1S0o9Zft6yu7rpFjf18klqOqqoP+87FM9BQFm1WctLR02
n0e4NY7akryVH7/W0uDJkV4n5Ye7j8F98VAagoxCSrk8lX3AhAaMBzrbFjzstxJw
o8Vlt3ZTC1d7L8wbgFTEZtErmBKruTRV3BqOEhu9aiao2uwPe2Jhb0D5rjuHCvcF
DqmIhODWsfxuoy5uHy0wL4oSjttEfF8x5jtB3DBVrEBN+tReed5asNMfeQAZQqSZ
fIJ9gXbVE6FTJz8MrLHsn0dculG3lQezddYbc0TMPxg4f0v8sj2xk/LV2lXdTV/o
eB4VbRqkwiT+J/+SHE+TAQDcQCw44rbOCuZx8rzyvwD1W+Jw0IUIIvNwnB7y2HBX
uQwAnLbEC6D8dvYXJc1ltV3eBYiCwneO4S/WX4C9Yp1y0kQLILybbRaOyF41L9OE
7xeFnmr9xnNfS7MgKjdVAm6P99xuZic1S6uC7r8oaL3/R69coO/nwOEN5eVMwpwp
x2tt/Nhig2QT8kyjlVIZe7oppDpf/PWk8SxAXZgwWSa23nawMtp4P9L4VaPbwnPw
kT0nY4RI60jAZmG00GC0cYjomPGnfkg1vfJoGnSMghz7f7+syXGOEIE6SZLCKE1m
hssJmh390x6gAPQjKohU62micEm0VVGEax+fUN0jTnCpp8BXYSWbY66FB1dL4Mtl
o+2i1+7O5hJvnylrLCfRheETazlW/xqxS4ZBk2olaC8FZF1Tqo66rBlFDPVOm8de
rlACppC/px+apDDTZju3UaWPhMIPlhP9M3vkgouJgHRhqvAH9ZgwtlFV9v1wvyOn
91cQFC1y0YKkptIn6X2mlgiZIoizq8no5X0Eq+RtffCJlqDsfj9WncKlk4Oh5Bk6
FFfJC/sGlv7BkhORO1kHZZTHD7arCI3vOSJu8b+W9FnbKLho1/So9wnjQoFe6PO/
Q6PbNvNJnTCSwCEvxm1L7XBLIJtO5uOrrKge5BXNT9a/+oUMem702UU9bydcTF2m
Ux4TbLlstnXa4C+9821aZltSb+pnGPkNBGwprpP6cOTx1TIb6rUmpPqKdVDTMpeg
kDVeSDltOJShTstXH1y3h39WwRuH9c/tnW+m7lpyGmz2yVL4itU7qadygO6u06/2
SuLiyg+WSNh/s6LBsS+Qx+6MwXqs69JXcB13/BK5uqP2ub1ilBN/7aqTIMoESK2l
GHO+g8m3q1Cn0JSZ/ohMC8HMqU8NaHcv4jAh5yRds+UQ7YkxuwIpoxNgawNkW2rk
22JKkuCQWAb04Iiq5sBQSijlfkJoPVLiDW4mMhvrUs7ru1bu+mFS5G3vV/xem7xC
dDxLvIYslX8onZsVqxuzHmZLEXFstz/rfVQMH03I6rqt82Ogf9boNGYxvPUi+WqB
EwmdoFe0JFRvYmlhcyBNdWVsbGVyIDx0b2JpYXNtdWVAZ25vbWUub3JnPoh/BBMR
CAAnBQJarZOvAhsDBQkJZgGABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJECaz
85GJw5f2jcoBAIxZr3oM7QObsHgXE3Aawi3oqsC3KYKv+u431WPsmM1UAQCZpc2F
fVHEa+4234cTmCnQbbFrCXxIeB8k2myZ76Hg+rkDDQRarZOvEAwAkwSKzWkK6pYk
sa6LgZdRKjGghFcwCFprptDyAv9iLfs/s+8zfUhHD2stliStDNtuGvhYeN0/o7T/
F6TJ9JZX0QhI/+LqeQTWvRsZ9KoevSpTp0SpNfQa66b+WCfeGIw9BwKnNn+p5SNc
kxjP3DZvyH57CzctoA8yFiAXK0OTijNiBO89llyCLCdmMHR/BANwg/Lv1AWL/M0a
4oibQR6+GR8T+3ydzaZvkxn+hNdTE50YslWFzXXR0brivparCWijUUpnn3Prgaus
wKvOz8QFfe8Qz037ydd8XXd40S3IA4/GYnuVn+opaxGVMsjMNh1yhYp5AiYU1VD4
FTXdKLZRMXtDr+TTB1qSN6KCJ7EQ/O/tWY704ldIE3zLKQV4dYXDhau4jKx1j9yz
xkb4PpJD+b6NBvwNGoTvw4iBsRNXwRho0WMYo304Dh64edBhMC/h3lhj+wCQONR7
yYv0l3hY8pmJXY409uCGwWUoQ9yr+ynk+fM7vNfOeZA6mVoJCuQbAAMFC/98wKAL
VNTDpmsQvZNebGkYUB2QxEeGtcqUaRly/DcKveb3SpJ4CRrxTVBsZQVVeHYbOQPH
5cKOWprV5RUV08urNVxY5Dlu3PCZTMHT2L2otPGiInxk0CRFOWheo5lu7LRdQMSI
i8m+1iP5heQrfTVt+2vS/ogkMtWbjWRaj1gzHQ0wEEtz+bF8t4f6pjQSUKU7R35g
z4GqTbDG+BsW5yD5tMG+2+Ide/c0dl4aGSmBHwJdhL/78Zi//z2VNt1h89rk8zyL
pfZVl6sq78ukqy30or9LWRkDSYrl8WKrLGXWzQgWLgN97Srd7dXRVqRZqVG7/3mG
6PbQzUiYj+pcItJfhGCp8oVwOBpnhNnywxsAGk5f2G4B9XUWv21aE4ZzaQLi0DnA
3+kzTLULI6yd6LfdhjEJaj1TcW8gxWgRGkyU/5mva9pXvYr5yZzNGxXAyLFliuNU
QHfPbuokGlr/ERy9J8CMmT2LYY+eocCeMpN/oyaZX9j2C4pqei41/Ich5M2IZwQY
EQgADwUCWq2TrwIbDAUJCWYBgAAKCRAms/ORicOX9rrnAQDBKBceDhsxXKWZQvuR
Me/juPtunEHhxSiPQa1i61djCgD5ATxw0MjcM/bRHiPFj8JJmvKeRfrZLMZsdNCA
BkK1L5A=
=Aij5
-----END PGP PUBLIC KEY BLOCK-----