Author Topic: Beta: fSekrit 1.40 needs some abuse! (Read 58,716 times)

f0dder · « **on:** October 07, 2009, 07:41 PM »

After almost two years of inactivity, and being embarrassed by reproducable data loss, I finally kicked my own butt around a bit. This beta needs some heavy testing, since I reworked the file-save logic. It should be a lot more robust now, but because of the changes it definitely needs some beating around.

1.40 BETA5:

fixed: Read-only notes should be a lot more sane - changed to "Save As Read-only"
fixed: NT4 and Win9x support should be back again.

1.40 BETA4:

fixed: font selection dialog initialized to show current font selection.
added: recognition and hyperlinking of URLs.

1.40 BETA3:

fixed: font selection dialog should work on all Windows versions now (*crosses fingers*)
added: "portable mode" - create a file called "fSekrit.portable" in the same folder as your fSekrit document, and %TEMP% won't be used for the temporary-editor-executable.

1.40 BETA2:

added: font selection dialog, no longer do you need to much around with the registry to set another default font. The font is still not stored in your document, though, and is single global per-user registry setting.

1.40 BETA1:

fixed: long-standing bug where failing to save changes when closing fSekrit with a modified document would cause fSekrit to exit, rather than notifying of error and let user attempt to save again.
fixed: saves are *finally* done properly, by saving to a temporary file and replacing the current file only when all the file writing business is done.

mouser · « **Reply #1 on:** October 07, 2009, 07:42 PM »

new version! good fixes too.

rgdot · « **Reply #2 on:** October 07, 2009, 07:56 PM »

Thanx f0dder

f0dder · « **Reply #3 on:** October 09, 2009, 01:53 PM »

Beta#2 added

insertnamehere · « **Reply #4 on:** October 29, 2009, 06:11 PM »

So I fiddled with bets2 for a little while and noticed a couple things.

The make read-only command -> it only makes it read only until you close the file. Should this command be modifying the properties of the file so that it stays as read-only or is this made to just protect it from changes after you have it open? (which needs to be repeated every time it's opened)

If the file is set to read-only from the properties menu in windows, when you go to save it dumps a "fsk****.tmp" file in the same location as the executable. I'm assuming this is normal. I expected it to fail saving since it was set to read only, this is just an observation.

The choose font.. command does not see any of my fonts. I receive a message saying There are no fonts installed. Open the Fonts folder from the Control Panel to install fonts.

There's a chance Spybot Search and Destroy 1.6.2 no longer detects the temp file created in "%UserProfile%\Local Settings\Temp\" directory as a trojan but I need to verify this which I will do later on today. (on windows xp sp3)

This was tested on Vista Business SP2 x86.

Thanks f0dder!

mwb1100 · « **Reply #5 on:** October 29, 2009, 07:08 PM »

When using fsekrit at work I get some minor problems because the McAfee stuff they use here has an Access protection setting for programs that run from the temp directory:

Quote

C:\WINDOWS\Explorer.EXE C:\Documents and Settings\userID\Local Settings\Temp\fSekrit-225C.exe Common Standard Protection:Prevent common programs from running files from the Temp folder Action blocked : Execute

It's not a big deal, because right now it's just set to log, not to actually block anything. However, it does show up in the logs, so it appears that I'm running malware infected (or otherwise questionable) stuff. It would be best if that could be avoided. I wonder if the following might be possible without too much effort:

- allow a command line option, registry setting and/or ini file setting that tells fsekrit where to put the temp file. Still default to the temp directory (which allows portable, no-install use), but let the user override if desired.

Thanks for a nice little tool.

f0dder · « **Reply #6 on:** October 29, 2009, 11:34 PM »

insertnamehere: ah, the read-only option is something that I had forgotten about, but which has always been "a slight bit" quirky

. Good that you mention it, it's a thing I really should iron out before going to non-beta, because it's clearly unintuitive right now (I just played around with read-only a bit, and found it pretty confusing - did manage to produce a read-only document though, but don't ask me how

).

Guess I'll have to test the font picker a bit more, it's pretty simple code so wouldn't have expected it to go wrong - I'll test on XP and Vista tomorrow.

mwb1100: it makes sense to be suspicious about running out of %temp%, but damn some of those HIPS thingies annoy me

- adding a registry setting should be a pretty quick fix, as long as you don't ask for a GUI option for it

insertnamehere · « **Reply #7 on:** October 29, 2009, 11:55 PM »

Haha alright, sounds good. I'll play around with it some more on xp pro sp3 x86 and see how it compares to the results I got on my laptop running vista business. I asked about the read-only thing just because I wasn't quite sure what the intended function was - whether it's supposed to produce a read-only file or just keep it read-only for that session.

Let me know if there's anything in particular you would like me to test. One thing I haven't tried is running it under server 2003...

Aha! Same deal with the fonts on my desktop running XP. This happens both with a new unsaved file as well as one that has been saved and has had no changes made to it. Tested with and without highlighting the text (probably a moot point).

Stoic Joker · « **Reply #8 on:** October 30, 2009, 12:33 AM »

Quote from: f0dder on October 29, 2009, 11:34 PM

Guess I'll have to test the font picker a bit more, it's pretty simple code so wouldn't have expected it to go wrong - I'll test on XP and Vista tomorrow.

I don't have access to a Vista machine at the moment, but I can confirm the no fonts error in XP x86 (VPC). However running on my main Win7 pro x64 machine it loads the fonts just fine (come to think of it...isn't that what you're running also?).

Update - Server 2008 is close enough to Vista (i think) and it gives the no fonts error also.

f0dder · « **Reply #9 on:** October 30, 2009, 12:35 AM »

Quote from: Stoic Joker on October 30, 2009, 12:33 AM

Quote from: f0dder on October 29, 2009, 11:34 PM
Guess I'll have to test the font picker a bit more, it's pretty simple code so wouldn't have expected it to go wrong - I'll test on XP and Vista tomorrow.
I don't have access to a Vista machine at the moment, but I can confirm the no fonts error in XP x86 (VPC). However running on my main Win7 pro x64 machine it loads the fonts just fine (come to think of it...isn't that what you're running also?).

Yep, it is - I'm probably just filling a structure slightly wrong, missing a flag or something. Adding the selection dialog was a 10-minute job, didn't think it would be necessary testing something that simple rigorously on several systems

Stoic Joker · « **Reply #10 on:** October 30, 2009, 12:42 AM »

If you still have the T-Clock source I sent you a while back its got a font selection dialog that works on all the above (might save you some time).

insertnamehere · « **Reply #11 on:** November 04, 2009, 08:52 PM »

Just a minor update -> the trojan deal with temp files and Spybot Search & Destroy has been corrected with the latest updates. 1.35 and 1.40 show up clean now

irh · « **Reply #12 on:** November 07, 2009, 11:21 AM »

This is more of a question that a comment

When FSEKRIT creates a temporary file prior to confirming the save has worked - is the temporary file securely overwritten with random data or "o"s in order to remove a security risk?

Also, one feature that would be a huge bonus would be for FSEKRIT to reconnise hyperlinks i.e. a 1 click jump to an URL if the url was included in the text

Is this likely anytime soon?

f0dder · « **Reply #13 on:** November 07, 2009, 01:23 PM »

Quote from: irh on November 07, 2009, 11:21 AM

When FSEKRIT creates a temporary file prior to confirming the save has worked - is the temporary file securely overwritten with random data or "o"s in order to remove a security risk?

No, and there's not much reason to - data is never stored unencrypted. Also, the executable stored in %TEMP% contains only fSekrit itself, none of your own data.

Quote from: irh on November 07, 2009, 11:21 AM

Also, one feature that would be a huge bonus would be for FSEKRIT to reconnise hyperlinks i.e. a 1 click jump to an URL if the url was included in the text

Would be a nice feature, but I don't know how much work it'd take... I'll see if it can be done with the standard RichEdit control without too much fuzz

irh · « **Reply #14 on:** November 07, 2009, 01:47 PM »

f0dder - thanks for the explanation

great news on the hyperlink issue - thanks for looking at this

Writer · « **Reply #15 on:** November 08, 2009, 06:28 AM »

One problem with fSekrit I have found is that it uses a new name everytime it opens. I understand this is is required. However, there are times when it is necessary to inform clipboard viewers that you do NOT want it to capture the clipboard update.

While you're making changes to the code, would you be able to implement this flag too:
http://www.clipboardextender.com/developing-clipboard-aware-programs-for-windows/ignoring-clipboard-updates-with-the-cf_clipboard_viewer_ignore-clipboard-format

f0dder · « **Reply #16 on:** November 08, 2009, 01:09 PM »

Quote from: Writer on November 08, 2009, 06:28 AM

One problem with fSekrit I have found is that it uses a new name everytime it opens. I understand this is is required. However, there are times when it is necessary to inform clipboard viewers that you do NOT want it to capture the clipboard update.

I do have to add that random part to the filename - petition your clipboard software developers to add wildcard matching to it's ignore list?

Quote from: Writer on November 08, 2009, 06:28 AM

While you're making changes to the code, would you be able to implement this flag too:
http://www.clipboardextender.com/developing-clipboard-aware-programs-for-windows/ignoring-clipboard-updates-with-the-cf_clipboard_viewer_ignore-clipboard-format

Interesting idea - thing is, I don't do any handling of the clipboard myself, but let the RichEdit control handle it. I could take over and do all this handling manually, but I'm not sure it's worth it...

Writer · « **Reply #17 on:** November 08, 2009, 06:49 PM »

I understand your reluctance to touch clipboard control. I use Clipmate, and the developer doesn't want to implement wildcard matching. Well...

f0dder · « **Reply #18 on:** November 08, 2009, 08:12 PM »

Quote from: Writer on November 08, 2009, 06:49 PM

I understand your reluctance to touch clipboard control. I use Clipmate, and the developer doesn't want to implement wildcard matching. Well...

Seems a bit arrogant to introduce a clipboard format extension for other people to use, but not wanting to implement a 5-minute wildcard matching - you say it already has the capability to do (non-wildcard) blocking?

It's not that I think the clipboard blocking thing is a bad idea as such, at least not if "all the relevant people" support it. It's just that it's a somewhat-considerable amount of extra work for something that's handled entirely automatically right now

f0dder · « **Reply #19 on:** November 15, 2009, 05:46 PM »

Beta #3 added

Stoic Joker · « **Reply #20 on:** November 15, 2009, 07:53 PM »

Fonts work for me in:
Win7 x64
Server 2008 x86
Server 2003 x86
Windows 2000

Program does not run on WinNT ... and I'm guesing you don't care either

f0dder · « **Reply #21 on:** November 15, 2009, 08:21 PM »

WinNT as in NT4?

For most development these days, I'd not care about any Windows version below Win2k, and perhaps I'd even accept XP as minimal platform... but I kinda want fSekrit to run basically everywhere, I made some specific code parts for handling Win9x. Not sure if moving to a more recent Visual Studio has messed that up, though - I really need to get 9x, NT4 and Win2k virtual machines set up again.

Thanks for testing the font selection

Stoic Joker · « **Reply #22 on:** November 15, 2009, 09:56 PM »

Yes NT4 sp6a, I'd assumed it didn't matter (I never code for anything older then 2k either) but the error was something to the effect of "Program is not a valid Windows NT executable"

f0dder · « **Reply #23 on:** November 16, 2009, 07:07 AM »

Quote from: Stoic Joker on November 15, 2009, 09:56 PM

Yes NT4 sp6a, I'd assumed it didn't matter (I never code for anything older then 2k either) but the error was something to the effect of "Program is not a valid Windows NT executable"

I'm thinking that might have to do with the "image load configuration" (which only XP-and-later support) that later versions of Visual Studio add to PE executables; should be ignored on older Windows versions, but some versions are preeeetty picky/peculiar about how they validate executables prior to running.

I probably won't have time to do a VM install before the weekend, but I might have time to produce a test executable with that load-config section nuked, if you care to test it for me

Stoic Joker · « **Reply #24 on:** November 16, 2009, 12:14 PM »

Sure I can do that.

I'm still using MSVS2005 which has the option (enabled by default) Make Win98 compatable exe. So MSVS2008 calls it something else (and disables it ('bout time really)) ... or am I totally of base.