PyTom wrote:
Spiky Caterpillar wrote:
Also, while I'm not a cryptographer, last I looked, it appeared that vanilla RSA signatures may have been broken a few years ago; while there is a padded RSA approach that's supposed to get around this, the padded one was patented at the time.
I don't believe these attacks are relevant to the way Ren'Py uses RSA. There's an attack that uses the chinese remainder theorem to recover plain texts, but since we're just signing, this doesn't apply. The exponent for the keys we use is also in the good range.
There are some unlikely attacks that padding might prevent. It would be pretty easy to fake a signature for a file with md5s of 00000000000000000000000000000001 or 00000000000000000000000000000000 - but I don't think there's an attack against md5 that allows this. I'm also a little scared by crypto patents on padding, I don't know if they've expired yet.
I'd thought that attacks on encryption could be transformed into attacks on signing - but crypto remains uncomfortably opaque to me.
I suspect they're still in force; Magical Diary uses both unpadded RSA and DSA and rejects the catalog if either signature fails (so at least I hopefully haven't made it worse.). Magical Diary's updater also takes out all the text-file related automagic conversions, on the grounds that it's a lot more likely that I'll intentionally create a file where LF/CRLF differences matter than that I'll intentionally upload using a protocol that converts line endings in transit.
It's practical to create files with colliding MD5sums - see
http://th.informatik.uni-mannheim.de/People/lucks/HashCollisions/ . I'm not sure if that can be extended to get a specific target MD5sum, but it does make me nervous.
PyTom wrote:
The strategy I'm considering for the next-gen updater will be:
1) Create a tar archive out of the non-generated files on disk - pretty much everything by .pyc and .pyo files.
2) Use
zsync to update that file based on the information stored on the server.
3) Decompress the tar archive, putting the files in the right places.
You'll likely also want to add in automatic regeneration of generated files, to avoid UAC-related weirdness on Vista/Seven.
zsync sounds like it may well wind up being useful to me as well - I've been leaving all the new files unarchived to avoid patches triggering a redownload of my titanic .rpa. (Which isn't really a problem at the moment, as I'm half-hoping to encourage fanmods, but.)
cyrus_zuo wrote:
The issue is for developers that VNs are something difficult to make money on selling. So a paid version or paid assets are likely only to appeal to a very small group.
They aren't *that* difficult to sell IMO, but yes, developers are a small group. And a picky group - if five other Lemmasoft users have bought a given asset pack, I probably don't want to use the same asset pack for fear of looking too much like the rest.
What I would do if I wanted to monetize Ren'Py more effectively is to ignore the *developer* market and go straight to the end users. Most of the games on
http://games.renpy.org/category/commercial have affiliate programs, and the commercial game userbase is much broader than the developer userbase.
cyrus_zuo wrote:
So ads allow anyone to casually earn some income off of a free game on Android, w/o having to sell it directly. That seems like something that would appeal to a larger group of RenPy users than the other options discussed so far.
It's a big mistake to assume that ads are something you can just plonk in and forget about while the money trickles into your bank accounts. There's a large inherent conflict of short-term interest between users and advertisers: malware droppers, fraudsters, and just plain annoying advertisers often PAY BETTER than legitimate businesses with inoffensive advertisements do. It's not in the adspace vendor's short-term interest to pay an employee to chase away customers, which means it's likely to wind up being YOUR job as a game author to make sure that your advertisers aren't misbehaving.