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.

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.

added: "portable" mode, which (for now) means it will not use %TEMP% to store it's temporary editor executable, but instead store it in the same folder as the opened document. Registry is still used for font selection, though! To enable this feature, create a file called "fSekrit.portable" in the same folder as the document you want to function in portable mode.

added: URLs are now recognized and turned into hyperlinks.

fixed: Read-only notes should be a lot more sane - changed from confusing "make read-only" that half-worked to "Save As Read-only" that works

fixed: Win9x and NT4 support has been broken since version 1.35. Release builds are now done with an older compiler toolchain, and 9x/NT4 support is back

Thanks f0dder - this is the only way I have felt comfortable having a private chat with family and friends over the Internet. Using prearranged passwords we are able to send attachments back and forth. I never felt that way using PGP, etc., but maybe I wasn't using them right. Now where did I put those Cody Coins...

I'd like to have those:1. Setting to choose if cursor should be at the beginning, the end or the last remembered position2. Setting to paste current date/time on the end of file, on opening (as default for notepad with .LOG in the first line)

I'd like to have those:1. Setting to choose if cursor should be at the beginning, the end or the last remembered position2. Setting to paste current date/time on the end of file, on opening (as default for notepad with .LOG in the first line)

Good ideas - I'm planning to upgrade the container/document format so I can add arbitrary new settings without requiring further modification of the document format. Once that's done, saving settings like this per-document will be a breeze

Hi,I am starting to use it on a regular basis and I have a few suggestions/observations/questions :1/ When a text has been saved in read-only, could it be possible to turn r/w on again, without creating a new file2/ Would it be possible to enter a unique password at the beginning of a session so that files created next are all saved with the same password, which would reduce input errors.3/ When typing the password at save time, could it be possible to un-hide the password (optionally)4/ Is the support of "rich text" doable a in future version ?

Great tools as it is, but I feel this would improve my user experience even more...

Edited :5/ Also, when I open a read-only note, select new, the new file is still read-only, so it's impossible to enter text.

1) I've been considering this, but don't really know - the original request for read-only actually wanted it to be even more restrictive than it is. Which use-case leads to enabling and then disabling read-only mode?

2) You can already achieve this by choosing "Save As"... I could do a "don't clear passphrase on file->new" option, which would be easy for current version of fSekrit. However, it would be more intuitive for file->new to open a new fSekrit editor window, rather than the current method of just clearing the contents. If/when that is added, the cache feature would require passing the passphrase on the commandline (or some more complicated IPC method), which I don't really feel like doing. Commandline is a security risk, other IPC method is too much code overhead for too little win. I'll ponder a bit about this.

3) yep, and it's something I've wanted to add. Next version will have copy/paste disabled on the passphrase dialogs, but an "unmask password" checkbox (which will obviously clear whatever you've already typed when you unhide).

4) should be, considering I'm using a RichEdit control - actually I'm currently specifying explicitly that I only want pure text on edit->paste, it'd be less code to acched rich formatted text. I do not plan on adding rich editing features to fSekrit, but pasting from an external document should be doable.

That use-case sounds fair enough, but then we'll also have to consider why you enable read-only... as I interpret the original request, it was to avoid "tampering" with the encrypted notes. To achieve general "protect me against my fumble-finger saving", you could set the +R attribute on your file.

But let's have a discussion about this . And if you have anything to say about the other four points (or anything else), let me know - I'm open for comments.

About the +R attribute, I thought at first it was equivalent to the 'read-only' feature and was looking for this attribute to be set (I never read the manual!).

Lifting the 'read-only' atttribute makes sense when you want to update the content of a note easily but not inadvertedly. If fsekrit could ask for the password when doing it, it would avoid accidental change of the note content and still give some flexibility ?

Regarding hide/unhide password , I understand the temptation for erasing but it would only enhance security in a not indispensable way. If you're in an "open" environnement, with some eyes behind you, you just don't leave your PC and don't unhide the password. I would keep the two input zones, without erasing, but simply unhidden. This would solve the important problem of Caps lock or numlock being activated and a different password being typed than the one you want, especially if you also remove copy/paste.

While I rarely use the read-only feature myself, I like the possibility to save permanently read-only files and I don't think you should make it possible to make them writable again. That would only reduce it's function to the previously mentioned "protect me against my fumble-finger saving", and I'm having a hard time imagining how you could both accidentally edit a document, AND accidentally save the document afterward. For people who need that you have the +R attribute.

My point is just that sometimes you realise you've used the read-on feature too soon ! And you are also just proving my point by saying "I'm having a hard time imagining how you could both accidentally edit a document, AND accidentally save the document afterward". If so, there is no obstacle making it R/W again since you won't erase the read-only version unintentionally.

Nope, it's outside the scope of fSekrit, which is to stay LEAN_AND_MEAN. I really, really really wouldn't worry about AES-256 not being strong enough... not now, and not in the next umphteen years. If you're in a position where you could be compromised by anybody even remotely likely to be capable of breaking AES-256, I'd worry much more about Rubber-hose cryptanalysis.

BTW, since I installed Avast V6 free, I keep getting annoyed by messages related to Avast Sandbox : it usually insists on executing it within a sandbox, and no rule to prevent this can be easily defined since the application is launched from the user temp folder with a different name each time, such as fSekrit-02C5.exe.

I could disable the sandbox altogether, but since most alarms come from fsekrit, maybe something else could be done ?

MerleOne, you can use the "fsekrit.portable" approach to have the editor executable created in the same folder as the "document" itself - but it will still involve creating a temporary exe. Unfortunately there isn't really any way around this, a temporary exe is necessary in order to update the main exe. I've been pondering whether I should add a "installed" mode where a global installed fSekrit.exe is used as editor, but there's a few problems with that approach as well.