> Fortunately, and this is still not common with free software, we have now established a way of financing the development while keeping all our software free and freely available for everyone.
> Our model is similar to the way RedHat manages RHEL and Fedora:
I looked around the website for a bit and didn't find a blog post or anything indicating what they've replaced the donation revenue stream with. Have they been employed? Are they doing consulting?
"GnuPG VS-Desktop" has been approved by the BSI for encrypting secret files/messages in the German government (VS=Verschlusssache) so I'm guessing that's where most of the money is coming from.
The BSI is great though, they know what they are doing. Also the German government supports Open Source projects financially [1] and one of the states is planning to go full open source in its administration, so you'd think they are interested in keeping these projects alive
I support some form of FOSS guilds, in moderation; that is, there is knowledge that is documented but not necessarily full, complete tutorial and discussion casually provided. Obviously many companies do this explicitly themselves now with "community documentation" or "public core" and then many other media assets that are not shared widely. This is natural and obvious, with caveats that fairness is inherently difficult, and you can't please everyone. Security practice is certainly the sort of world where that guild behavior can go badly, and many will complain, sometimes falsely. So it goes in the real world.
Corporate and government users have been free-riding FOSS to ridiculous levels, in my view, and I welcome some way that actual practitioners can self-organize and at least survive. As opposed to say, divorce, substance abuse and what amounts to financial suicide, which I have seen happen to real people with good intentions and bright minds.
“ GnuPG.com, Düsseldorf, Germany
Offers commercial grade support, customized development, porting to new platforms, help with integrating GnuPG into customer projects, code audits, and more. GnuPG.com is a brand of g10code GmbH; owned and run by GnuPG´s and Gpg4win´s principal authors.”
There is certainly a need for consultants to help organizations do PGP-style security well. And it doesn't look like they're transforming GnuPG into an open core product model with critical components only available commercially.
So, this seems good? It doesn't look like they've been bought by anybody (e.g. a VC) who's going to require the sort of rate of return that can only be attempted (and probably not achieved) by doing things incompatible with GnuPG's role in the open source ecosystem. Not every company has to be huge — GnuPG can have outsized positive impact on the world while remaining small and sustainable.
I'm confused as well, it's not clear from that post what the new structure is, or how sustainable, or if there are back-up plans. It just says, that there is a new structure essentially.
I'd appreciate it if someone helped me understand, or get more context.
1. a lack of good support via an API/libraries (the standard way to communicate with it seemed to be shelling out to the binary and trying to parse its output
for a long time)
2. terrible UX, especially around the trust model - web of trust is great in theory and for geeks but doesn't work well in practice, and the terms used to explain it invited dangerous misinterpretations (to mark a key as trusted in the sense of "I verified that this fingerprint belongs to that person", you're expected to sign it, NOT mark it as "trusted" - the latter actually causes all keys signed by that key to be trusted, making it a "CA").
These may be addressed by now, but I think this is too little too late.
I dont think those are addressed now. I needed gpg for the first time recently. After fiddling with documentation and weird terms, approaches etc I decided it is not worth whatever it does. My time would be better spent if I learned how to knit or something.
Very confusing post. It doesn’t explain how they are now making money--which is probably relevant for some folks to trust them to protect online privacy.
I think they did explain it, although I had to read it a few times to find it. If I understand correctly, they're charging for "the actual binary of the MSI installer for Windows and client specific configuration files." It sounds like they're doing so under the name "GnuPG VS-Desktop." I think it's related to selling services through https://gnupg.com/gnupg-desktop.de.html, but I'm not entirely sure.
> Those with SEPA donations, please cancel them and redirect your funds to other projects which are more in need of financial support. The donations done via Stripe or PayPal have already been canceled.
> Werner Koch wrote the software, known as Gnu Privacy Guard, in 1997, and since then has been almost single-handedly keeping it alive with patches and updates from his home in Erkrath, Germany. Now 53, he is running out of money and patience with being underfunded.
Recall that this was in the wake of Heartbleed, a vulnerability that exposed our dependence on OpenSSL, another critical, and chronically underfunded project.
The project got a nice boost after that article, leading to this Ars Technica story about the windfall:
> Given the ramshackle state of massive GnuPG code base, it's not clear what's the best path forward.
Comparing the list of CVEs for major cryptographic software OpenSSL, OpenVPN, OpenSSH and GnuPG implementation of OpenPGP, GnuPG has stood up pretty well for three decades:
The main shortcoming of OpenPGP standard is lack of modern authentication. It has MDC, which works in most cases, but isn’t best practice nowadays. There is an update to RFC4880 in progress, RFC4880bis draft, which is presumably considered by sequoia-gpg. The file format is also apparently disliked by some people, but end users care about results. If RFC4880bis is standardized, the gap between OpenPGP and alternatives is closed. Then, using a heavily audited standard and code is preferred.
I read GnuPG is used by organizations requiring high security, eg, intelligence agencies, NSA, state-level actors (presumably shadow brokers etc), banks etc.
It’s still good to have competing options. But let’s focus on facts.
This does not look like an especially reassuring track record! People should keep in mind that GnuPG is a legacy C codebase. Nobody would implement a tool like GnuPG in 2021 the way GnuPG is implemented; we accept its implementation because of path dependency, not because it's especially sound.
I don't think your supposition that GnuPG is beloved of "NSA and state-level actors" really qualifies as "facts". The industry standard "secure email" system for banks is simply a TLS web interface that you post your emails to; banks don't use PGP for secure communications. I haven't, of course, worked for all the banks, so if you've got a counterexample, please provide those facts for us to evaluate.
Obviously, the documentation of a proposed design for AEAD support in an RFC doesn't close the gap --- users care about results, as you say, and so what matters, to the exclusion of all else --- is what the installed base of GnuPG clients supports. Which is why Sequoia's years of support of (I think?) EAX mode AEAD encryption hasn't moved the needle for the moribund PGP ecosystem.
It’s hard to meaningfully define and measure software security. One needs to also prescribe a threat model, provide other information, etc. This could take pages.
If you measure software security track record by the number of known CVEs per unit time per unit task per LOC, the track record of GnuPG/OpenPGP is about that of OpenSSH/SSH and OpenVPN; see the site I linked. I think most people would agree that OpenSSH is secure (although SSH is a similarly dated protocol).
The fact that a security product is used by organizations dealing with highly sensitive information in fact correlates with the quality of that product. The security researchers in these organizations review, vet and recommend that software, compared to alternatives.
GnuPG dutifully implements OpenPGP. OpenPGP has shortcomings I noted, but their impact on experimental results has been low; see the list of registered vulnerabilities.
There is a lot of critical software and applications written in memory unsafe C (Wireguard, Linux network stack, LUKS, popular password managers, etc). They are well regarded, despite being written in C.
The use of GnuPG by important organizations is stated in GnuPG’s website. The examples I provided are well known and may be found using a search engine.
SSH is in fact not "similarly dated" to PGP! SSH roughly tracks the maturity of TLS (I'd say SSH is generally a step behind TLS, but not several steps); neither is completely mired in the 1990s. The same isn't true of PGP, which is. That's to be expected: GPG is a global ecosystem of direct, interoperating peers, where both TLS and SSH can upgrade incrementally in islands of new implementations, which gradually expand and agglomerate until the worst of the O.G. designs can be disabled.
By way of example: if you build a new fleet of machines, it's very likely that your SSH sessions will use 25519 curves and a Chapoly AEAD.
OpenPGP is, for this reason, pretty much irrelevant. You can ratify any bit of modern cryptography you like in OpenPGP standards, but because everyone in the PGP ecosystem expects to be able to communicate with everybody else, you'll only be able to use the lowest common denominator of whatever widely-installed old versions of GnuPG support.
You could, of course, refuse to interoperate with people speaking CAST5-CFB or whatever, and form a clique of Sequioa PGP users using EAX and, I don't know, P-curve ECDSA? But at that point, you're only going to be able to communicate with a tiny subset of PGP (itself a tiny subset of all secure messaging users). Why bother with PGP at all at that point?
Because if sequoia is good enough from a security standpoint with standards and implementation and ux experience, people and organizations will switch from gpg to sequoia, for example perhaps at debian.
and if organizations/projects like debian switch, developers will switch, and developers are multipliers and users will switch at one point as well.
Like, I know intellectually that this must happen, but my experience (which tilts much more to investment banks, to be fair) is that an FTP server with plaintext files is much more common.
I can confirm that banks do this. They do ftp as well but to exchange credentials they’ll use PGP. The hardest part is identity verification which is often done with a phone call.
Since OpenPGP is normally used in offline and stateless applications like encrypted email and encrypted files there is no need for some sort of session oriented authentication. The content itself is signed and thus authenticated. So the MDC is not normally needed either, it is just an integrity check for the edge case of unauthenticated encryption. The only time the alleged deficiencies of the MDC come into play is when doing symmetrical encryption.
This is good; donating to GnuPG was not an especially effective way of protecting at-risk users, and it's better that the project be supported by the niche userbase (apparently: the German government) that actually uses PGP in 2021, rather than trying to make a social cause out of a (pretty controversial) file format.
I think there are multiple reasons it's good. It's good for security as you've articulated.
It's also good as an example of sustainable open source development via the consulting model. We've seen a lot of hand-wringing about FOSS funding lately. It may not be as flashy or high-profile as VC-funded open core projects with all their ubiquitous marketing, beautiful websites, and submarine PR. But it's a way to make a living by exchanging useful value in exchange for moderate fees, rather than asking for charity or signing up for an unsustainable investment deal.
I agree. That seems like the real story here, and it's good that the top of this thread is still about the funding mechanics at play here and not another endless relitigation of the (contested) value of PGP itself.
I've always found it annoying that there isn't a properly supported python package for gnupg. There were like two or three forks that were maintained properly but each one had its "time". It's very confusing for people to begin with using PGP since you have to understand which one to use and the history and why they all exists. A lot of fuss if you ask me.
There's a package called PGPy. It's a python implementation of PGP. BSD-3-Clause licensed. https://github.com/SecurityInnovation/PGPy When testing it out GnuPG compatibility, I just had to add the --rfc4880 when encrypting with GnuPG. Then PGPy could decrypt it using the private key generated by GnuPG. PGPy supports key generation and encryption too.
We can use stronger terms here --- whatever else you think of PGP, the shell-out stdio "api" for PGP is dangerous (GnuPG will release unauthenticated ciphertext to "callers" of that API, with a warning you need to catch). This API was responsible for the Efail bugs --- which were horrible --- a few years ago. Don't ever do this.
How is that any more dangerous than a "real" library doing the same? Your code would still have to check whether the message passed the integrity check or not, just like it has to look for the warning on stderr. I can't imagine why doing a stream search for i.e. "WARNING: Verification failed!" is any less secure than checking result.verificationPassed (assuming the CLI messages won't change, which they won't since they're basically an API).
You could just as easily say a "real" command line interface wouldn't do the same thing.
Of course, it might make more sense for a library, "real" or not, to default to raising an exception with no output, not just a warning - especially for a security-critical application. But it's not like we've never seen unsafe defaults in a library before, even a crypto one.
Then again, it does make sense from a UX standpoint: I'd rather see "message could not be verified", followed by the decrypted content anyways, rather than not get any output. I know not to trust it, so knowing what it says is useful in terms of threat identification.
This is really not a CLI vs DLL issue - it's a default settings issue. And in this specific case, the unsafe option actually follows the standard more closely - it does not, after all, mandate integrity checking. Mybe it should, but that's a different conversation.
(Disclaimer: I'm not very knowledgeable with GPG, I assume that the warning means that the message hasn't been properly signed.)
> I'd rather see "message could not be verified", followed by the decrypted content anyways, rather than not get any output. I know not to trust it, so knowing what it says is useful in terms of threat identification.
You would know not to trust it, but it would be very easy for a novice user without an understanding of the implications to assume that it's just a minor error ("tech sometimes throws errors, but it works anyway, so why worry?"). But it damn sure is not!
My suggestion would be to print an elaborate and strong warning about the implications and provide an option to look at the message if you really know that it should not be trusted in the slightest.
This is how browsers handle TLS certificate issues and I'd call it a lot safer than showing the website anyway and displaying a small warning with some technical jargon.
> Except for the actual binary of the MSI installer for Windows and client specific configuration files, all the software is available under the GNU GPL and other Open Source licenses.
They’re paying for a Windows installer. Building Windows code from source is not something most Windows users are capable of.
well then, redirect your funds to sequoia-pgp.org then. they make a good alternative, which is more secure than gpg. several former gnupg developers work on that as werner did not want to work on citrical issues back then.
Age can't authenticate when encrypting to a public key because it doesn't support signatures. So don't use it in this mode unless you know what you are doing.
Most people should just use GPG for stuff like this.
Nobody should be using GnuPG casually; if you're still using it in 2021, you should have a really clear reason for doing so. You're virtually always better off using any other well-known tool. The reasons you've provided in the past for defaulting to GnuPG --- such as its avoidance of authenticated encryption being a good data recovery mechanism --- have, to put it gently, not seemed especially informed by cryptographic best practices. It seems like more of a social cause for you than an engineering decisions. Which is fine as far as it goes, but it'd be better if you were clearer about that.
I use it indirectly with pass (passwordstore.org), which is one of the few security-related pieces of software I like. Do you have an opinion on that? I've never heard of age before, but it looks like a pass-like interface to it could be ejected in a few hours if one were so inclined.
Is the antipathy towards GPG based on it being too easy to misuse/misapply, or is it because it's broken when used properly?
I've heard nothing but good things about pass. There's also a pass that uses age now, which is I guess what I'd use if I was in the market for something like it. There's a point at which you're asking so little from your cryptosystem --- as is the case with local-only CLI password managers --- that it doesn't much matter that you're using PGP. I don't, like, recoil from .pgp.asc files! The place you really get in trouble with PGP is when you try to use it on email.
>The reasons you've provided in the past for defaulting to GnuPG --- such as its avoidance of authenticated encryption being a good data recovery mechanism --- have, to put it gently, not seemed especially informed by cryptographic best practices.
That greatly misrepresents my position. Generally I prefer that things follow some sort of open standard. For offline capable, stateless encryption that leaves the OpenPGP standard. I have spent some time looking at it and judge it to be completely OK and worthy of use. I was even inspired to write a series of articles about it in an attempt to counteract the misinformation that I have seen:
The requirement for signatures to authenticate public key encryption is inherent. OpenPGP includes it because it is for all practical purposes mandatory. It isn't some sort of useless frill.
PGP (and its de facto reference implementation in GnuPG) is not the main player in this space, unless you define the space down to a point so small and idiosyncratic that it doesn't really have meaning in an broad discussion.
It's both. GnuPG has very poor UX and it's also so old and so well-known that it kills a lot of the "unknown upstarts". I think on balance GnuPG reduces the security of network communications and the appeal of a web of trust PKI because it's presented as "the main player", people try to use it, realize that the UX is garbage, and become disillusioned in the technology behind it.
Eh, it's pretty new, and new cryptosystems are often more likely to have vulnerabilities. It's still safer than PGP, but that's not a high bar. Hopefully over the coming years it will become more widely used and scrutinized with few vulnerabilities reported, in which case it will then be more clearly safe to rely on.
I also have never heard of Age. Then again, I don’t actively keep up-to-date with the world of cryptography (other than from a PKI/X.509/TLS perspective) . As a system administrator, I only use GnuPG to check the signatures of software packages and to exchange passwords with other sysadmins.
This thread has been both interesting and educational.
Serious question: how read into work on cryptography engineering and secure messaging do you feel you are? I'm trying to get a gauge of what it means to be "brand new" for you. What cipher constructions are OK? The CAESAR finalists? The AEADs Rogaway surveys in his papers? The ones GnuPG supports?
It seems weird to me to gauge someone’s understanding of “brand new” for cryptography software by measuring against primitives and constructions. To me at least, those are not the same thing. Even if a piece of software contains cryptography I will still also evaluate its age as a piece of software simply as a proxy for maturity and stability of the feature set.
No it was a comment trying to indicate that I found your question odd, and ask why you think your question is useful? Do you believe there is a single notion of brand new that can be applied across all categories? Is the age for brand new milk the same as for software or for scientific results or items of clothing? Or do you believe that for the categories of software and cryptographic theory the notion of brand new is equivalent?
Frankly in my reading of your question you come across as very arrogant, where you use the guise of a “serious question” to show off your knowledge cryptography.
I also agree with adament. It may not be responsive to your question but your question doesn't read in good faith and many of your other comments in this thread read as pitiless war against an opponent you've decided is your enemy.
There have been many articles written that push back against the narrative a small cohort of security people push that GnuPG and OpenPGP by extension should be avoided at all costs. Personally, I find it has stood the test of time admirably and that its "multi-tool" functionality unlocks features I use almost every day like a web of trust in Keybase and using it as an ssh agent. I actually don't want another tiny tool in age. With Sequoia the future of PGP looks bright.
You're trying to tell us that software from 2019 isn't new? The majority of the software that I use on a daily basis is minimum a decade old, and I don't think I'm alone.
Yeah, and it is supposedly a software related to cryptography. Has it been audited at least? They are promoting it so much, but GnuPG has been around for a while now and loads of people have used it. What about Age? I feel more comfortable with GnuPG.
I am sure audits could help Age either way. :) I am just saying that it is still fresh as opposed to GnuPG. This is what people typically call "battle-tested", when the software has been used by a zillion of people for some time. Of course I cannot speak about Age much, this is the first time I heard about it.
Hell, I have shirts older than the language it's written in.
In 20 years, I might not even be able to find a working compiler to build it, after the shiny-object crowd moves on to something else.
You know what I'll still be able to decrypt? An ASCII-armored, GPG encrypted, TAR archive.
Personally, I am not interested in the latest evolutionary improvements on file formats. Evolution produces a lot of interesting things; most of them are dead ends. What I want is the cockroach of file formats. The coelacanth.
You will be able to decrypt a file produced by age. All the cryptography there is standard, you'll have a compatible library in whatever language you'll use in 20 years, if you think the first party Go and Rust implementations won't survive.
Using common libraries, I can create a python program to decrypt a file produced by age in a few hours, I think.
No. Brand new means completely new. Something that's going on 3 years old isn't brand new anymore.
A more appropriately term is relatively new. Civilization is relatively new compared to the age of the universe. Age is relatively new compared to modern computers.
So don't use WhatsApp. That's a reasonable decision to make! I don't ever opt into it or recommend it to people (though I'd happily use it in preference to PGP email, which is doubtlessly the most risky secure messaging implementation on the Internet, arguably even more dangerous than simply using ordinary plaintext email with Google Mail).
It didn't try to do what you put on that list. It didn't do messaging; messaging programs used it. It didn't do backups; backup programs used it.
It's just a foundation-sort of program that does encryption and signing of arbitrary data, using one format for keys, and allowing working with those keys whether they're in the same computer or in a smartcard/hsm. That simplifies key management, since it allows you to have one Yubikey with your PGP key on it and do basically anything crypto related.
But what I believe someguydave was referring to was stuff like smartcard/Yubikey support, not different uses of encryption and signing.
age can't sign, though. It's not as useful. You can't use it for authentication, for instance. You need a separate program with a separate key and its own separate yubikey support.
I was more thinking of the extensive support GPG has in many email clients on many platforms for supporting encryption and signing use cases, as well as key management.
Thank you! I was unfamiliar with both age and Cwtch. From what I can tell, Cwtch is also a linear messaging system. Are you aware of any software offering secure non-linear (hopefully threaded) messaging, i.e. a secure e-mail replacement? It does not have to be MIME, SMTP, IMAP based like PGP, but preferably support for similar branching conversations and archiving and hopefully with support for multiple users. I love Signal but I find that finding old messages, or groups with more than a few people and branching conversations is a lot less pleasant than e-mail. And thus Signal is not currently a replacement for e-mail for me but a great addition.
>Encrypted backups: age + a Reed-Solomon encoder for catching flipped bits
I fear that I might of caused this idea. I have as a result added the following footnote to the article that I suspect is the cause[1]:
>Please note that the single flipped bit here is not a realistic example and that in practice damage tends to encompass one or more media blocks. Such blocks tend to be multiples of 512 bytes.
I am afraid that someone might actually implement this...
Has it been independently audited at all? I looked around and didn't find anything about it.
It's probably maybe fine, and of course code can change at any time, but with software focused on security, it would seem more necessary than, say, an audio player (excluding improbable situations).
Either way, It's nice to see a GPG alt written in Go.
Too late to edit my comment: I had misinterpreted “a GPG alt” as meaning a GnuPG alternative implementation of OpenPGP. Only after reading the parent and other ancestral comments did I realise that Age was the project being discussed and that it’s an alternative to OpenPGP – not just GnuPG.
The only thing PGP did correctly, and very well, is the concept of persistent identity. Keybase recognized this and uses PGP as the toehold, then from there, created a secure auditable chain of NACL keys. The PGP 'web of trust' and non-repudiability nature of PGP messages each failed for good reason.
This PGP-style concept of persistent identity is almost always the opposite of what you want from a secure messenger, where meta-information about who's exchanging messages with whom is often just as valuable as the message content itself. When the NSA identified Reality Winner communicating with The Intercept, they didn't so much care about what was in those messages; once the link was established, they had better ways of extracting the rest of the information they wanted than trying to defeat a cryptosystem.
> When the NSA identified Reality Winner communicating with The Intercept, they didn't so much care about what was in those messages; once the link was established, they had better ways of extracting the rest of the information they wanted than trying to defeat a cryptosystem.
Which is surely a strong argument for having keys that are standalone and portable across different communication media, rather than having them be coupled to accounts on particular services (or, worse, to personal information like an SSN or phone number).
I haven't heard of this before. How does it compare to Sigstore?
(Also, the use case here is clearly much, much narrower than for age and minisign. Which is good, assuming the problem it solves is the problem you have, but should still be noted.)
What ecosystems are out there where I can flick a switch and say 1. "automatically install signed releases" or 2. "automatically install releases signed by multiple identities"?
Are any of the big language-specific ecosystems capable of that? (npm, crates.io, composer, PyPI, CPAN, Maven, rubygems, etc.)
It's not quite flick a switch, but with maven you can specify which keys you trust to sign which of your dependencies (anything published to maven central is required to be signed). E.g. here's one of my libraries: https://github.com/m50d/tierney/blob/master/free/keys.proper...
Nothing really yet. Containers got relatively close with Notary V1, I'm focused on fixing that here in sigstore right now. I think Python, Ruby, and NPM would be great targets to go after next!
Gossamer is a 2017 design of an idea that was first published in 2015. However, it was exclusively focused on the PHP community from its inception, so it's unsurprising that nobody's heard of it.
Is there a straightforward way to use attestations to gate automatic updates?
For example, it would be nice to delay automatic updates of WordPress plugins and themes until after there is more than just the uploader's identity as a single point of failure guaranteeing that the update is genuine.
(Obviously the perfect way to do things given enough developer resources is to review all code yourself before installing manually, but it would be nice to improve situations where those resources are not available.)
The intention was to allow security vendors to offer code reviews of open source dependencies, and you can choose which you trust. This mechanizes Linus's Law and ensures there's an audit trail with "many eyeballs".
This seems like critical prerequisite infrastructure, which is fantastic — although not yet what I was asking for. As far as I can tell there is not yet a way for individual WordPress installations to actually benefit. However, it seems that work is underway: https://gossamer.tools/project/wordpress
> The intention was to allow security vendors to offer code reviews of open source dependencies
What I care most about is just quorum publishing where multiple independent identities sign a release, so that an attacker has to compromise multiple trusted identities to execute a supply chain attack. I'm not too excited about reviews beyond that. The main thing is to upgrade collective ecosystem security by hardening automatic updates.
More specifically, Trillian is analogous to Chronicle, which is what Gossamer uses as its underlying ledger. But yeah, there's a lot of similarities. You're on the right track. :)
Age doesn't do signing because PGP's signing mechanics have been one of the biggest fiascos in popular cryptography (to this day, mainstream PGP use via GnuPG doesn't produce authenticated ciphertext, due to confusion on the part of PGP's designers on the distinction between authentication and signatures). In day-to-day encrypted secure messaging, durable signatures are one of those things that sound great but are actually the opposite of what you want.
The most widespread practical use of PGP's signature capabilities are for package systems, where the actual contents of the package aren't confidential to begin with; PGP is only being used to sign. But PGP signatures are clumsy and archaic, and there are better tools to get the same capability without PGP's baggage --- notably the "signify" scheme that OpenBSD came up with and that minisign implements.
Can you reword this? I'm not sure what you're saying here. Are you asking me to go into more detail on the difference between a signature and a message authentication tag?
age doesn't replace everything PGP does, which is good, because PGP does too many things. It just replaces the use case of file encryption (which itself is arguably too general; it's perhaps best to think of age as a good fallback for encryption use cases that don't have a better domain-specific tool). See https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
> Our model is similar to the way RedHat manages RHEL and Fedora:
I looked around the website for a bit and didn't find a blog post or anything indicating what they've replaced the donation revenue stream with. Have they been employed? Are they doing consulting?