Live data from Hacker News

Email Encryption Software Relies on One Guy, Who Is Going Broke

propublica.org

461–469 of 469 posts

Re: Email Encryption Software Relies on One Guy, Who Is Going Broke

#461

This shouldn't be odd to anyone who's spent a large amount of time releasing open source. You just end up being used and uncompensated. At best you get a job offer from it. It's really sad to me how many companies benefit from open source (including my own software) without the author ever being compensated. It's hard for me to get motivated to do anything open source anymore because of the feeling that I'm just a gu…

If you are going to expect being compensated, why are you making free software to start with? Why not make a paid one instead?

Re: Email Encryption Software Relies on One Guy, Who Is Going Broke

#462

Earlier quoted context omitted.

By all means. Ed25519 (which underlies signify) is a pretty decent modern signature scheme. (tweetnacl.c also implements it, in less code.) It also seems you want to expire things, so I do feel I have to warn you that signatures are a totally separate thing to a secure time source, which is a whole different bag of marbles. However, since what you're designing sounds like a logic bomb/copy protection/DRM system, I mu…

So, use case would be something like: Software is shareware, gets a little naggy within 30 days of license expiration, send money to get a new license file, which makes the nagging go away. No cessation of service. I'm not worried about clock spoofing--I assume basically good-faith customers. Signing would help people from just copy-pasting certificates around. If they want to go into the executable and rewrite the r…

If you assume basically good-faith users: why nag them? After they registered? Aren't they assuming basically good-faith authors? Why do you think people who you'd nag after they registered would copy-paste keys but not download a crack?

(Your registrations are time-limited? That's very unusual for self-described "shareware". That's pretty much "commercial, but your demo nags".)

You're welcome to choose whatever business model works for you, of course, but take it from me, this one's straight from the early '90s. I hope it works for your users too.

Re: Email Encryption Software Relies on One Guy, Who Is Going Broke

#463
post #373

Earlier quoted context omitted.

By all means. Ed25519 (which underlies signify) is a pretty decent modern signature scheme. (tweetnacl.c also implements it, in less code.) It also seems you want to expire things, so I do feel I have to warn you that signatures are a totally separate thing to a secure time source, which is a whole different bag of marbles. However, since what you're designing sounds like a logic bomb/copy protection/DRM system, I mu…

It's a non-trivial task to design software that will deliberately fail and cannot be easily by-passed with a debugger.

A massive understatement, for any software that is itself non-trivial.

And unfortunately, the harder someone tries to reach that goal, the more fragile their software becomes. A lose/lose situation.

It really is better to engineer software to work, not to fail.

Re: Email Encryption Software Relies on One Guy, Who Is Going Broke

#464

Earlier quoted context omitted.

Then is selling apps on app stores not profitable anymore? I was under the impression that it was.

Assuming I'm reading this [1] right, the FSF seem to believe that Apple App Store (where the majority of mobile app profits are being made) isn't compatible with the GPL. [1] https://www.fsf.org/blogs/licensing/more-about-the-app-store...

You don't have to have the Apple store to have an app store. I believe Apple even lost in court the exclusive trademark rights to "app store".

Re: Email Encryption Software Relies on One Guy, Who Is Going Broke

#465

Earlier quoted context omitted.

> open source and free for non-commercial, require a donation if it is used in a commercial product Every serious definition of 'open source' or 'free software' says that you can't discriminate by field of endeavour - if you have one set of rules for commercial use and one for non-commercial use, it's not really open source. And the nature of donations is that you can't require them. That's not to say that you can't…

Your mention of exceptions to the GPL is probably what the OP was talking about http://en.wikipedia.org/wiki/Multi-licensing It might be a little tricky in the case of GPG since it is really a GPL port of the commercial PGP software. So a major reason for it's original existence is that it is GPL code.

Gpg is not a port of some PGP version but an implementation of rfc4880 and earlier open standards. I actually took great care not to look at any "open source" PGP code. The reasons why dual-licensing does not work is that I assigned the copyright to the FSF in 1998 and when I terminated that contract 2 years ago too many other other hackers have code in it or assigned it to the FSF. Thus there is no way for anyone to switch to a dual-license.

Re: Email Encryption Software Relies on One Guy, Who Is Going Broke

#466
post #411
post #326

I would like to repost a comment from reddit[1] that makes some good points: "That title is pretty laughable. Enterprise E-Mail Encryption solutions do NOT use gnupg, and most enterprise customers do not even use openpgp, they use X.509/SMIME. I know the world top 10 server side enterprise e-mail encryption solutions and the majority uses java with either bouncycastle or ajak encryption, for PGP or openssl/bouncycast…

I tried to submit a patch for GnuPG that would enable it to use "proprietary" PKCS#11 smart-cards instead of "open" OpenPGP smart-cards. Line of though being, users may already have S/MIME generated keys on their smart-cards, so why not use the same keys with PGP too? In the end, a key is just a number. The request was refused [1] with ridiculous arguments [1] about PKCS#11 not being "needed in free software world".…

It was not about proprietary smartcards but about the proprietary driver software required to use those smartcards.

If the vendors would open the specs of their smartcards it would be easy to write a driver. Some did and we support them in GnuPG. Most of them don't and we may even assume they want to hide their little secrets in their drivers. It is all the same as with all the proprietary hardware drivers. Look at decades of LKML for similar discussions.

Re: Email Encryption Software Relies on One Guy, Who Is Going Broke

#467
post #466
post #411

Earlier quoted context omitted.

I tried to submit a patch for GnuPG that would enable it to use "proprietary" PKCS#11 smart-cards instead of "open" OpenPGP smart-cards. Line of though being, users may already have S/MIME generated keys on their smart-cards, so why not use the same keys with PGP too? In the end, a key is just a number. The request was refused [1] with ridiculous arguments [1] about PKCS#11 not being "needed in free software world".…

It was not about proprietary smartcards but about the proprietary driver software required to use those smartcards. If the vendors would open the specs of their smartcards it would be easy to write a driver. Some did and we support them in GnuPG. Most of them don't and we may even assume they want to hide their little secrets in their drivers. It is all the same as with all the proprietary hardware drivers. Look at d…

Sorry, I don't buy this. PKCS#11 is a standard, wide-spread, user-space API for accessing cryptographic tokens, just like POSIX is a standard API to access operating system services. I guess it's about the time to write a "driver" for each supported OS instead of relying on libc, because the user's installation cannot be trusted?

Re: Email Encryption Software Relies on One Guy, Who Is Going Broke

#468

Earlier quoted context omitted.

Strange you cannot seem to just donate to the Linux Foundation, you have to become a member?

Yes you can: https://www.linuxfoundation.org/participate/linux-donate

Oh my bad.

Re: Email Encryption Software Relies on One Guy, Who Is Going Broke

#469

Earlier quoted context omitted.

Assuming I'm reading this [1] right, the FSF seem to believe that Apple App Store (where the majority of mobile app profits are being made) isn't compatible with the GPL. [1] https://www.fsf.org/blogs/licensing/more-about-the-app-store...

You don't have to have the Apple store to have an app store. I believe Apple even lost in court the exclusive trademark rights to "app store".

You don't, but as I pointed out this seems to be where the majority of app revenue still comes from. Cutting that out as an option makes it much more difficult to make much money from app development.
Post reply on HN