TiddlySaver.jar available

[PVHL]

I just published an unsigned TiddlySaver.jar to my TW GitHub fork that should work for everyone. Jeremy suggested we label this as an Alpha until it is tested and signed. A signed version should be coming fairly soon, along with a move to Beta status.

 

Recent Java updates broke TiddlySaver because some of the code uses instructions that Oracle has now made unavailable to applets. This version simply changes an existing flag, turning off the code that checks if the file being read or saved is in the same directory, or a subdirectory, of the Tiddlywiki file it is running in.

 

The fix works for me in all the browsers I've tested, but does open the TiddlySaver applet to potential abuse if one's java policy file is too permissive. It is a good idea, therefore, to create a restricted policy file for your TW files that specifies which directories the applet can write to. Personally, I leave reads wide open and restrict writes to the directories I want to be written to. So my policy file (for Windows; see the TW notes for *NIX variations), assuming my TW file is in C:\tw, looks something like:

 

grant codeBase "file:C:/tw/TiddlySaver.jar" {
    permission java.io.FilePermission "<<ALL FILES>>", "read";
    permission java.io.FilePermission "C:${/}tw${/}*", "write";
};

with an extra write permission line for each additional subdirectory. Not ideal, but workable; I'm not aware of a way to include subdirectories, nor do I know if this is the best choice for a policy file; frankly, I'm not too worried about it, but still don't want to make writes generally available Just In Case.

 

I will be rewriting the Java code soon(ish) to re-implement the 'same directory' restriction with unblocked instructions. If anyone knows a good way to access the applet's directory using the current Java version please let me know; my current intent is to make the browser pass in the applet's directory as a parameter to either the applet or the Javascript calls, though this will obviously break backward compatibility.

 

Cheers, Paul.

[PVHL]

BTW, one could of course use:

 

grant codeBase "file:C:/tw/TiddlySaver.jar" {

    permission java.io.FilePermission "C:${/}tw${/}*", "read, write";
};

again with a new line for each directory or subdirectory. I personally use TiddlySaver in another project where I need to read files from just about anywhere for importing purposes. I don't think this is needed for TiddlyWiki.

[David Bakin]

FYI, to save other people the trouble of looking for it, here's information about the java policy file: http://docs.oracle.com/javase/1.4.2/docs/guide/security/PolicyFiles.html

 

You can find it in the subdirectory lib/security of wherever your sun/oracle JVM is installed, called 'java.policy'.

[Yakov]

Hi Paul,

as you can deal with Java, may be you can take a look at this issue [1]?

Best regards,
Yakov.

[1] https://github.com/TiddlyWiki/tiddlywiki/issues/124

четверг, 24 октября 2013 г., 6:45:27 UTC+4 пользователь PVHL написал:

[PVHL]

@all [reposted after reading #172 again; haven't found a way to edit posts and new to Google Groups]

 

I asked above if people knew how to allow subdirectories, and just read TW ticket #172 that explains how. Apparently:

 

grant codeBase "file:C:/tw/TiddlySaver.jar" {

    permission java.io.FilePermission "C:${/}tw", "read, write";
    permission java.io.FilePermission "C:${/}tw${/}-", "read, write";
};

 

will do what I wanted ('-' instead of '*'; amazingly difficult to discover this stuff from official Java sources). I haven't tested this yet, but #172 says it works, and I want to correct my previous information.

 

Since writing, testing, and publishing my small code change I have been having permission issues using it that I didn't have when testing (haven't tested the above yet); not sure if a Java update changed things and I'm still looking into it. Has anyone had success with my modified TiddlySaver?

 

@Yakov

I'd certainly look at the destroy method you pointed to, but it seems like a bad idea so far. Is closing the browser instance not possible as a workaround? I'm also wondering why you couldn't use Java7 on Windows 7, as it has worked fine for me on several Windows 7 setups.

[Yakov]

Hi Paul,

Closing browser doesn't help. The unload time is the same as in the case of just closing TW.

About Java 7 -- well, it didn't work for me in a number of setups [1]. May be I have to research the issue again, but this would require some time and efforts. Which I actually want to invest into the exploration of another approach for saving [2].. (about which I don't know if it's feasible).

Best regards,
Yakov.

[1] https://groups.google.com/forum/?fromgroups=#!topic/tiddlywikidev/8xEMu4eXwZk
[2] https://groups.google.com/forum/?fromgroups=#!topic/tiddlywiki/25LbvckJ3S8

воскресенье, 27 октября 2013 г., 9:00:05 UTC+4 пользователь PVHL написал:

[perlguy]

On Saturday, October 26, 2013 10:00:05 PM UTC-7, PVHL wrote:

Since writing, testing, and publishing my small code change I have been having permission issues using it that I didn't have when testing (haven't tested the above yet); not sure if a Java update changed things and I'm still looking into it. Has anyone had success with my modified TiddlySaver?

Fedora 19

luakit and (webkitgtk 2.0.4) and chrome (30.0.1599.114)

your latest TiddlySaver.jar on git (8221 bytes, md5sum 40940c33746590faa902f95414a80bd7)

TW 2.6.1, Java 1.7.0_25, works fine, with block/unblock prompt once every session. Chrome also shows the "Java out-of-date, update/run?" once per session, unless you use '--allow-outdated-plugins'.  I'm reading up on how to mix signed and unsigned code without triggering the warning - might just have to set things to 'unblock, with protection' as the default.

TW 2.6.1, Java 1.7.0_45, fails with the TW generic "It's not possible to save changes" message.

TW 2.8.1, Java 1.7.0_25, TW falls back to downloading the html file on save.

TW 2.8.1, Java 1.7.0_45, TW falls back to downloading the html file on save.

[PVHL]

@perlguy Much appreciated report; thanks. Good to know how things are working in Linux.

 

@ all

 

I am no Java security expert, but have been spending several days researching (and banging my head on the desk!). Today -- after many hours of fruitless work -- I decided to change my system policy file in a last ditch attempt to get 1.7.0_45 to work on my current set-up (WIndows 7, testing with portableapps.com Chrome and Opera, latest versions). Before this I was using the policy file location reported by the Java console and it worked until the last update to 45; I was not able to get TiddlySaver to work using the published user locations since update 25 (IIRC).

 

It is now working in both browsers with TW 2.6.5 and 2.8.1 (only versions I've tested) using the permissions I suggested earlier added to the end of the system policy file. Actually, I've made one change others might not want to use. I keep the various TW versions in separate directories below the TW directory (not the one shown here, but similar) and don't want to have a new permission for each directory. I've changed the 'grant' to the one shown below. This means that any Java code in 'C:\TW' and its subdirectories will be run, not just TiddlySaver, but for me this is not an issue (YMMV).

 

grant codeBase "file:C:/tw/-" {

    permission java.io.FilePermission "C:${/}tw", "read, write";
    permission java.io.FilePermission "C:${/}tw${/}-", "read, write";
};

 

Obviously this is less than ideal as it requires administrator approval, but I hope this helps a bit (as mentioned, I don't personally use the Java functionality).

 

(For anyone else using portableApps, it turns out that Chrome uses the Windows policy file while Opera uses the PortableApps java (CommonFiles) policy file. Actually, my portable Java install is not up to date, so Opera is only using update 15; I will post again if Opera doesn't work after I update the portable Java install to 1.7.0_45.)

 

The latest update will apparently also necessitate changes to the TiddlySaver.jar manifest file before it works properly as a signed jar (and will then hopefully also survive future Oracle attacks), but I need to research this more when I have time. My guess is that this is also why the latest update is failing.

 

Hopefully a signed jar that works with updated policy files in current Java versions, and with old policy files pre-45, will be available in the next few weeks.

 

As always, I'd be grateful for any feedback, and/or pointers from Java security nerds.

 

Cheers, Paul.

 

[PVHL]

I have tested a signed version of the code and discovered there is a 1.7.0_45 bug that stops it working. (At some point I'll test earlier Java versions and post results)

 

Would love to get reports from those who have tried the unsigned code using the policy file settings I suggested above added to the system policy file and/or some other location that works for you. I can guarantee the applet will fail WITHOUT the grant permissions being loaded as it is unsigned.

 

Cheers, Paul.

[Daniel Hunsaker]

Working here on Windows 7 Enterprise SP1 under Chrome 30.0.1599.101m (wow, 30.x already?!!), after fiddling around with the system policy file.  It would be really nice if there was a way to do this without mucking about in there, but I understand that's unlikely.  I've never been a fan of the Oracle approach to just about anything.

Anyhow, just figured I'd check in on this.  The download fallback never worked for me; the data: URL it would build would base64-decode to a certain point, then the rest would be gibberish.  I suspect I have an encoding issue someplace, somehow, but I'm not concerned about it quite enough to hunt it down and kill it.  I'll be moving to TW5 as soon as it hits release anyway.

[Yakov]

Hello,

I guess this is of little interest, but I've tried the unsigned jar with Win7 x64 + Opera 12.16 + Sun Java 6 update 20 (I have also Oracle Java 7 update 17 installed, but Sun Java is loaded) + tw 2.7.1/2.8.1 -- both versions of TiddlyWiki don't save via Java (but the applet is loaded).

By the way, when talking about "latest version of Opera" it's worth mentioning that there are actually two "latest versions" -- among the 12.x series and among the new series (now Opera 17, I believe).

Best regards,
Yakov.

вторник, 5 ноября 2013 г., 3:39:28 UTC+4 пользователь PVHL написал:

[Devin Richards]

@Daniel I have just about the same configuration (Win7 Pro not Ent but same chrome) and I can not get it working. Can you detail what files you changed?  I added the lines from @PVHL to my C:\Program Files (x86)\Java\jre7\lib\security\java.policy file but it did not seem to do anything. I even moved my wiki dir to C:\tw just to be sure.

Thanks in advance.

-Devin

[Trevor Barnes]

Hi Guys,

I'm fairly new to TW and have been having the problems as described above in not being able to save changes when using Chrome : Version 30.0.1599.101 m + TiddlySaver.jar

I running Windows 7 Home with Java : Verion 7 Update 45  (build 1.7.0_45-b18).

However I discovered earlier this evening if I use the following setup I don't get any errors and changes appear to be saved.

Firefox v25 + Extension : Tiddlyfox 1.0alpha18 + Plugin : Java(TM) Platform SE 7 U45  10.45.2.18

Hope this is of interest.

-Trevor

[Eric Shulman]

On Wednesday, November 6, 2013 2:00:01 PM UTC-8, Trevor Barnes wrote:

However I discovered earlier this evening if I use the following setup I don't get any errors and changes appear to be saved.

Firefox v25 + Extension : Tiddlyfox 1.0alpha18 + Plugin : Java(TM) Platform SE 7 U45  10.45.2.18

TiddlySaver.jar is never used by FireFox (or IE for that matter).  In fact, when using FireFox+TiddlyFox, you don't even need Java installed on your system at all.

enjoy,

-e

Eric Shulman

TiddlyTools / ELS Design Studios

HELP ME TO HELP YOU - MAKE A CONTRIBUTION TO MY "TIP JAR"...

   http://tiddlytools.github.com/fundraising.html#MakeADonation

Professional TiddlyWiki Consulting Services...

Analysis, Design, and Custom Solutions:

   http://www.TiddlyTools.com/#Contact

[PVHL]

@Devin Did you put the TiddlySaver.jar from my fork in the same directory as the TW file? (i.e. both in c:\tw if that's what you used in the policy file -- you can replace the c:\tw in the grant statement with any path, of course, so long as they all match.) If you'd like to work on this some more I'd be happy to help via email, though FIrefox + TiddlyFox still seems the better solution to me.

 

@Daniel Thanks for reporting back. You have the same set-up as the one I tested on. I agree that messing with a policy file is unwanted, but without a signed jar it's the only way. If all the TWs are in/below a single directory, it only needs to be done once, if the above Oct 30th settings (or similar) are used. I'm not sure anyone will want to retrograde their Java install so I'm assuming there is little need for a signed jar right now, given it won't work in 1.7.0_45. Hopefully Oracle will fix the bug.

 

Cheers, Paul.

[PVHL]

Of course, if using the Oct 30th grant method and putting TWs in different subdirectories, each TW directory still needs its own copy of TiddlySaver.jar. (Still wishing there was an edit button for these posts!)

[Paul Levey]

@Yakov Sorry, I missed your post somehow. It works for me on Win7 x64 (Enterprise) using Opera 12.16 and latest Java, but I'm testing with the PortableApps version of both, not a full install. Also worked with an earlier Java version.

--
You received this message because you are subscribed to a topic in the Google Groups "TiddlyWiki" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tiddlywiki/kzPTzjJQA4I/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/groups/opt_out.

[Vincent Yeh]

Yakov & PVHL,

To support Yakov & PVHL, I am saying that I have high interest in this thread for Chrome has been my favorite browser (its the fastest among those I tested) for TiddlyWiki. However, I am not familiar with Java policy syntax so don't know how to apply it in my Ubuntu 13.10 environment, therefore haven't tried it yet. I would have if I knew how to modify the policy file for a Linux box.

Have fun!

Vincent

[Devin Richards]

@PVHL yes I put the wiki.html and the new TiddlySaver.jar both in C:\tw and then copied the grant statement from your post on Oct30 into my C:\Program Files (x86)\Java\jre7\lib\security\java.policy file and still get the error that my local policy has prevented a file from running, the name of the file is TiddlySaver and the location is just file://   

would appreciate any help you can give as I use my TW daily

[Tobias Beer]

Out of curiosity, what is the obstacle with creating a signed jar? Is that more than a click of a button /a whole approval process of sorts?

Tobias.

[PVHL]

@Tobias No obstacle; one has been created, though I haven't had time to test it with old java versions yet. The problem is that Oracle introduced a bug in the last Java update that stops it running if signed as noted in my Nov 4th post. The bug report is demonstrated here, though they've closed the report as not reproducible -- I can reproduce it (Win 7 enterprise), but can't see a way to comment on the Oracle site. They say it will work in update 51, but 51 will also stop unsigned jars working and requires manifest entries that I'm still researching. Hoping to have to have a signed jar that will work in the future updates rather than having one now that creates a flurry of "doesn't work" reports. Do you feel I should upload a signed jar for people to test that won't work in the next Java update? Let me know. I won't have time to do further work on this until I finish work elsewhere (hopefully on the weekend).

 

@Devin I wonder if your system policy settings are being overridden by your user policy file? As stated, I'm no expert in Java security and policy file use. I'm also wondering if WIn7 Enterprise uses policy files differently from other versions. I can't look into this at present.

[Devin Richards]

@PVHL I don't have a local policy file, just the one global, and I can't imagine that Win7 Ent is that different from Win7 Pro. Did I read that you were using a portable apps version of either TW or Chrome? I wonder if this makes a difference? Would UAC settings affect this? I am bothered by the fact that in the Java security pop-up the name of the file is just "file://" it does not point to the Jar.

[Devin Richards]

So I just realized that the pop-up I am seeing is NOT from Chrome, but Java so I opened with Windows Java Control Panel  and then on the Security tab I set security to Medium and now it prompts me to load the TiddlySaver.jar.

Yeah! it works!

HTH

[PVHL]

@Devin Well done. I completely forgot to mention Java security settings, though I spent quite a while playing with them myself before things worked. Aging brain.

 

@all This page tests if a Java applet (unsigned) will run on your current browser settings, tells you the version if it works, and gives some hints as to why if it doesn't. Another site that won't work with the Java update coming in the new year!

 

To quote the above page:

YOUR BROWSER LIES: Java 7 Update 10 introduced a new checkbox that disables the use of Java in all browsers. By and large, this is a good thing, but there seems to be a failure to communicate between Java and many web browsers. As a result, all the browsers I have tried so far incorrectly report that Java is not installed when, in fact, it may be installed but this new security feature has been enabled. Just an FYI.

[Chris Hecker]

I made a few changes to the policy file to hopefully be a bit more secure.  This is on Chrome, with java 7u51.

I had to set my java windows control panel global security setting to medium, which is idiotic, and I should be able to do this for a specific jar, but oh well.

The policy file is in c:/Program Files (x86)/Java/jre7/lib/security/java.policy for 32-bit java, and I found out the hard way that updating java stomps this file and you have to redo this.  You need to edit this file as administrator, I think.

I have my wiki in C:/users/checker/writing/wiki/, but instead of keeping the TiddlySaver.jar in that dir (which would make it writable by the below), I put in a jar/ subdir.  I had to modify my wiki source to load the archive:

archive='jar/TiddlySaver.jar'

Here is the policy snippet:
 

grant codeBase "file:C:/users/checker/writing/wiki/jar/TiddlySaver.jar" {
	permission java.io.FilePermission "C:${/}Users${/}checker${/}writing${/}wiki", "read, write";
	permission java.io.FilePermission "C:${/}Users${/}checker${/}writing${/}wiki${/}*", "read, write";
	permission java.io.FilePermission "C:${/}Users${/}checker${/}writing${/}wiki${/}wikibackups${/}*", "read, write";
};

my backups obviously go to wikibackups/

Hope this helps, and I think it's a bit safer than the original recommendation of keeping the jar file in the same dir as the wiki.

Chris

[PVHL]

> We should hopefully have a signed jar available that works in update 51 in the next few days. It will work with high security settings.

I thought I should add a link to the signed jar as this post is high up on searches. Please also read this entry describing use.

There will be a new TiddlySaver sometime soon that is signed with a new certificate. It will also be included with the official TWC. The current one will work even with the certificate expired.

[PVHL]

Hi Chris.

We should hopefully have a signed jar available that works in update 51 in the next few days. It will work with high security settings.

I see your point about using a different folder for the jar, but it isn't backward compatible. The current TiddlySaver can only save text files so there is little chance of TiddlySaver being used to write a new TiddlySaver, at least not one that works. (I am wanting to make a version that can save binary files for a different project, though, so your point is well taken.)

Cheers, Paul.