[Poll]: Password Protection for Quests

[Anarchy_Balsac]

The lure of ZC was never its passwords anyway. At most, it was probably an added bonus.

[_Mitch]

Yeah, it would probably be a waste of time, but that's something I find myself doing a lot (like right now)... I have a feeling my post was kinda misunderstood.
I'm sorta assuming there is no "bypassing" the encryption; the file is decoded before the data is actually read (that's usually the point of encryption).

If the decoding code is compiled, how would anyone get to see it? Obviously the encryption isn't that good (I have seen quite a few exploits for it myself).
Also, anyone could just use ollydbg and either dump the memory after loading the map, or patch ZQ so it skips the password altogether (with the current version, it's 5 bytes I have heard).

Although it doesn't matter how one would get in there, it's doable, and not very hard.
So yeah, I agree, it's probably best just to remove all of it, and label the password bytes in a quest as "obsolete" or "deprecated" password bytes.
But it's definitely not my decision how the password stuff is going to be handled anyways.

[_Mitch]

Honestly, I think ZC/ZQ would have probably been better off with it not implemented in the first place, unfortunately. :\

[SUCCESSOR]

Yeah, it would probably be a waste of time, but that's something I find myself doing a lot (like right now)... I have a feeling my post was kinda misunderstood.
I'm sorta assuming there is no "bypassing" the encryption; the file is decoded before the data is actually read (that's usually the point of encryption).

If the decoding code is compiled, how would anyone get to see it? Obviously the encryption isn't that good (I have seen quite a few exploits for it myself).
Also, anyone could just use ollydbg and either dump the memory after loading the map, or patch ZQ so it skips the password altogether (with the current version, it's 5 bytes I have heard).

Although it doesn't matter how one would get in there, it's doable, and not very hard.
So yeah, I agree, it's probably best just to remove all of it, and label the password bytes in a quest as "obsolete" or "deprecated" password bytes.
But it's definitely not my decision how the password stuff is going to be handled anyways.

You are still missing the obvious problem. If you encrypt all the data how will the quest player read it? Let's say you separate ZQ files and ZC files, one for developing and the other for playing. ZQ files could be encoded with whatever password you want and ZC files could have a common password for ZC decoding. No bypassing! Sound perfect? Well let's forget for a second that we have completely redone quest files and loading (a great deal of effort and time). How much effort do you think it will take to find out the common code? Or better yet let ZC do the decrypting and grab the unencrypted data?

We could do this all week long, but there is one simple fact that makes it all moot. Our less than secure passwords have worked for 15 years and they will work even after Open Source. Hell, they used to be stored in plain text.

[Tamamo]

merchant says just release as is will yeah encryption and all that jazz.

[_Mitch]

Why would they have been stored in plain text! How unoptimized. 0.o
I get what you are saying, and I'm not disagreeing, it's just, I would have thought it would have used something a little more complex than just a single encryption key.
I'm more into randomized encryption. Where the randomization seed is calculated through some sort of hashing procedure.
Still, whatever- passwords were kinda useless anyways, and it'd probably be better without them...

[Nicholas Steel]

I'm in favour of removing the password functionality and right now is a good time to decide such a major item of interest. Currently you can easily access and edit password protected quests made with Zelda Classic 2.50 through to 1.90 without issue, so the existing quests are already pretty much naked and if you were to improve quest encryption... the old copies of quests and Zquest will still float around the internet.

So yeah, either you do your darnedest to crack down on this and update all quests in the 2 quest databases and remove old copies of zquest and such or you just drop the issue and simply remove quest passwording. The latter doesn't run in to the issue of people hoarding old copies and websites maintaining old copies of stuff etc.

And making Zelda Classic Open Source will expose the inner workings of the password system, unless you exclude the code for it in the source code and try to maintain a separate branch or the program with it implemented but not publicly accessible and then people will probably favour the version that lacks DRM, maybe.

[Gleeok]

If everyone unanimously decided that they don't really care if the code for the passwords is made available or not, then it would be a bit simpler by virtue of not having different versions of ZC to have to manage. However, pretty much everyone would need to be on board with this, including the active community at purezc, not just the 10 people that voted so far.

Also just pointing out that you can't really remove passwords from ZC since they will always be needed to load older quests, but I get that "remove passwords" is not meant literally. Even if no one really cared about them anymore they would still stick around and you could still password quests, because ZC was just designed that way.

[ZoriaRPG]

The real problem, is the community perception of how 'safe' their content is, using the existing system. User John believes that by setting quest, and cheat passwords, he is doing something meaningful, and doesn't realise that it takes all of five seconds to bypass it, as it stands. Thus, they stand up on a soap box, and rant against removing this feature. I doubt there are many people here, on AGN, that we need to convince, but rather, the PZC crowd, is the bigger culprit. I suggested the library module as a quick-and-dirty way to skirt the issue, not as a valid method of security. If a user wants special levels of security, and encryption, clearly they would need to devise their own module for it; and the terms of GPL take a somewhat dim view on that, in general.

If all forward-changes to a source set, must be made available, a security method, would also need to be made available. A randomly generated key file, would therefore be the most secure, but it's something that users of the open-source code should be making, not the present project leaders, who rightfully feel that all of this is just a sheer waste of time. I concur. I suggested making the encryption itself, a module, that allows one of three inputs: User-defined, precompiled lib (using the stock method), or, best of all, none.

The real question, is whether the community at large can grow beyond the need for this false sense of protection.

Honestly, if the core devs opened up to the PZC community how the idea of not releasing the password and encryption routines as part of the source, was crippling future development, the perception of it would change in favour actual progress. I do not believe that the point has ever been nailed in to the heads of all the members, that this is more than simple logistics issue, and that it is indeed stalling exactly what they've wanted for years.

Hell, a developer strike would shake things up too.

Really though, the core devs posting a clear, concise, and explanatory topic on PZC may do the trick.

[CaRmAgE]

I'm on board with removing it. I never really saw the point to the password system, anyway, when it's so easy to bypass.