Here's version 1.3 of CPad, your open-source Perl/HTML/Text editing program!
There's only a few updates in this version:
Quote:
¤ Option to disable extensions (for commercial use, extensions may provide security holes and should be disabled). ¤ Open, Save, and Save As now remember the directory you were last working in, and what file extension to look for (based on what was just open. Default is .TXT).
In past versions of CPad, the "Open", "Save", and "Save As" would always start in the working directory, and always expect to work with only Perl files. This update will start you out in whatever directory you left off in, and will expect to work with whatever file extension you were using (for example, if you open "C:\homepage\index.html", and then do another Open, it will start you at "C:\homepage\" and list all the HTML documents by default).
I downloaded a binary version of CPad at school, and then told a friend how to get it (because we're working with HTML and CPad does syntax highlighting), and then was thinking that extensions could be used for malicious purposes (i.e. if every person in a network, i.e. a school, had access to CPad and extensions, they could hack the network).
So I added the option to disable extensions. The "prefs.ini" file now has an "ext=" variable, the value of this is an MD5-encrypted key. If the key is correct, extensions will be loaded. If the key doesn't exist or has been tampered with, extensions will NOT be loaded (and the "Extensions" menubar item won't even exist either ).
I like the idea of extension disabling... Certainly when it is run in a 'public' place like school or work. But i have my doubts about your method used.
I downloaded the binary version of CPAD 1.3 and checking into the contents of the zip i can see the .ini file is allready included with a MD5 hash inside the ext parameter.
Now, let's suppose the user has deleted this MD5 hash and is now working 'extension less'. Another user logs on to the same system, downloads the CPAD 1.3 zipfile and fetches the ini out, replacing the one that was edited.
I suppose this would just enable extension functions again, making it possible for the malicious user to install some 'tools' and 'suprise' the unwary user coming back to his CPAD and start it.
I like the idea of extension disabling... Certainly when it is run in a 'public' place like school or work. But i have my doubts about your method used.
I downloaded the binary version of CPAD 1.3 and checking into the contents of the zip i can see the .ini file is allready included with a MD5 hash inside the ext parameter.
Now, let's suppose the user has deleted this MD5 hash and is now working 'extension less'. Another user logs on to the same system, downloads the CPAD 1.3 zipfile and fetches the ini out, replacing the one that was edited.
I suppose this would just enable extension functions again, making it possible for the malicious user to install some 'tools' and 'suprise' the unwary user coming back to his CPAD and start it.
I couldn't come up with any more efficient ways of doing it. If I had tried using the registry (for Windows), that would scare away all *lazy*'all because you know registry editing isn't always safe.
Another idea (which was stated in the directions for disabling extensions), having a file on a different server that the public can't access. But the part that would point to that server would have to be somewhere that CPad could find it.
If I owned a huge public network and put CPad on it, I would put it on a different server, where the public can access the server but they have read-only access to it (so they couldn't modify the prefs.ini file). So even if they had the MD5 key, they wouldn't be able to activate extensions again.
If anybody has any better ideas, post them here. _________________ Current Site (2008) http://www.cuvou.com/
Joined: 19 Jul 2004 Posts: 556 Location: Los Angeles, CA votes: 1
Posted: Tue Feb 01, 2005 9:35 pm Post subject:
you could use an md5 for a password used to inablethem them just have the password "password" by default then an admin can change it or something _________________ [ matt ]
instead of putting a random string in, i suggest putting md5 hashes of the contents of all found tools in the ini. Then; when things don't add up you could put up a little window stating a new (altered) extension found, some info from the informative hashes and yes/no buttons...
Regarding registry... You could use it as a read only base for your 'install md5 hash', use the windows product key; or some other unique reg value to generate a key for your ini file, and therefor a unique ini for that system.
Not hard to make it multiplatform... Let it check OS then either use registry or /proc to retrieve a unique value for the system. I suggest hashing /proc/cpuinfo on linux.
You might like to register this at SourceForge. [right][snapback]45116[/snapback][/right]
I just sent a request to SourceForge to register it. I was working on a Cyan Chat client and registered that there, and so decided to register CPad too. It may not be accepted though since there's so many other text editors like it. _________________ Current Site (2008) http://www.cuvou.com/
User Control Panel
).
Another great creation! 
It may not be accepted though since there's so many other text editors like it. 
