Bug 191489

Summary: No feed can be loaded when rssowl ran on Sun JDK 5
Product: [Fedora] Fedora Reporter: Robin Green <greenrd>
Component: rssowlAssignee: Anthony Green <green>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 5CC: extras-qa, neugens
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-06-22 15:01:10 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Test to read encrypted data none

Description Robin Green 2006-05-12 13:17:22 UTC
Description of problem:
When rssowl is run on the Sun JDK, no feed can be loaded. I think the
CryptoManager patch added in Fedora Extras doesn't work on the Sun JDK, and I
think this is the reason why.

Version-Release number of selected component (if applicable):
rssowl-1.2.1-2.fc5

How reproducible:
Always

Steps to Reproduce:
1. Remove or rename any existing $HOME/.rssowl directory
2. Make Sun JDK 5 your default java (using alternatives or export PATH=...)
3. Run Rssowl
4. Double-click on any sample feed to load it
  
Actual results:
Feed loading stalls forever. In the terminal window, this appears:
Exception in thread "Update Manager Thread" java.lang.NullPointerException
        at net.sourceforge.rssowl.util.CryptoManager.hasItem(CryptoManager.java:125)
        at
net.sourceforge.rssowl.dao.ConnectionManager.<init>(ConnectionManager.java:96)
        at net.sourceforge.rssowl.util.shop.FileShop.getContent(FileShop.java:155)
        at
net.sourceforge.rssowl.controller.thread.UpdateManager.getVersion(UpdateManager.java:189)
        at
net.sourceforge.rssowl.controller.thread.UpdateManager.run(UpdateManager.java:117)
Exception in thread "Load Feed Thread" java.lang.NullPointerException
        at net.sourceforge.rssowl.util.CryptoManager.hasItem(CryptoManager.java:125)
        at
net.sourceforge.rssowl.dao.ConnectionManager.<init>(ConnectionManager.java:96)
        at
net.sourceforge.rssowl.dao.NewsfeedFactory.initXmlDocument(NewsfeedFactory.java:233)
        at
net.sourceforge.rssowl.dao.NewsfeedFactory.<init>(NewsfeedFactory.java:97)
        at
net.sourceforge.rssowl.dao.NewsfeedFactory.<init>(NewsfeedFactory.java:82)
        at
net.sourceforge.rssowl.controller.thread.FeedLoader.run(FeedLoader.java:139)
Exception in thread "Load Feed Thread" java.lang.NullPointerException
        at net.sourceforge.rssowl.util.CryptoManager.hasItem(CryptoManager.java:125)
        at
net.sourceforge.rssowl.dao.ConnectionManager.<init>(ConnectionManager.java:96)
        at
net.sourceforge.rssowl.dao.NewsfeedFactory.initXmlDocument(NewsfeedFactory.java:233)
        at
net.sourceforge.rssowl.dao.NewsfeedFactory.<init>(NewsfeedFactory.java:97)
        at
net.sourceforge.rssowl.dao.NewsfeedFactory.<init>(NewsfeedFactory.java:82)
        at
net.sourceforge.rssowl.controller.thread.FeedLoader.run(FeedLoader.java:139)
Exception in thread "Load Feed Thread" java.lang.NullPointerException
        at net.sourceforge.rssowl.util.CryptoManager.hasItem(CryptoManager.java:125)
        at
net.sourceforge.rssowl.dao.ConnectionManager.<init>(ConnectionManager.java:96)
        at
net.sourceforge.rssowl.dao.NewsfeedFactory.initXmlDocument(NewsfeedFactory.java:233)
        at
net.sourceforge.rssowl.dao.NewsfeedFactory.<init>(NewsfeedFactory.java:97)
        at
net.sourceforge.rssowl.dao.NewsfeedFactory.<init>(NewsfeedFactory.java:82)
        at
net.sourceforge.rssowl.controller.thread.FeedLoader.run(FeedLoader.java:139)


Expected results:
Feed should load eventually

Comment 1 Anthony Green 2006-05-12 13:34:38 UTC
I think you're right.  Line 125 is...
    return (key != null) && crypta.containsKey(key);
...which means crypta must be null.  Which means we're throwing an exception in
the CryptoManager constructor before calling loadData() which sets crypta.

So, either it can't find the Blowfish cipher, or... doesn't the Sun JRE require
digitally signed crypto provider jar files?

It seems that putting the loadData() call after the try/catch block in
CryptoManager() will at least make rssowl resistant to this problem, although
the data won't be encrypted on disk.



Comment 2 Robin Green 2006-05-12 17:05:28 UTC
rssowl doesn't use a master password AFAIK, unlike firefox, so its "encryption"
is really little more than obfuscation.

(By the way, the reason why there are 3 feed loader threads in my terminal
output is because I clicked on the feed 3 times, once to select, then
double-click to load it. It used to be necessary to double-click feeds in
rssowl, but it isn't any more, but I still do it out of habit.)

Comment 3 Mario Torre 2006-09-04 23:34:24 UTC
Created attachment 135516 [details]
Test to read encrypted data

Comment 4 Mario Torre 2006-09-04 23:35:02 UTC
Hi!

The lines that fail are the two Cipher.getInstance("Blowfish/ECB/PKCS7"); in
CryptoManager.java, (73/74).

Just using "Blowfish" is fine for both gcj/Classpath and Sun Java.

I have a test that reads data from the hidden file in ~/.rssowl/.user, where
rssowl stores encrypted data.

The test just reads data, it is used to check that changing "Blowfish/ECB/PKCS7"
into "Blowfish" still works.

There are a couple of possible issues, though.

The first one is that the old data is incompatible with the new one, raising an
exception of time javax.crypto.BadPaddingException when reading the hashtable.

The second one is that Sun java still need to be configured to use the right
provider. This can be done in a couple of ways, I found that adding a symlink on
the ext directory just works:

ln -s /usr/share/java/gcj-endorsed/bcprov-1.31.jar (or
/usr/share/java/gnu-crypto.jar) $JAVA_HOME/jre/lib/ext

where $JAVA_HOME is where the alternative system has put sun java.

Moreover, it is possible that the jce_policy file needs to be updated with the
unlimited strenght patch (you can get this from java.sun.com).

It may also be needed to update the java.security file to check for the new
providers.

All this requires some manual work... Another workaround could be to simply
ignore Sun java here, and force to use gcj despite the alternative system (for
example changing the command line that is built into /usr/bin/rssowl).

Hope that helps

Comment 5 Igor Jagec 2006-09-22 08:31:30 UTC
Mario Torre wrote:

> ln -s /usr/share/java/gcj-endorsed/bcprov-1.31.jar (or
> /usr/share/java/gnu-crypto.jar) $JAVA_HOME/jre/lib/ext
> where $JAVA_HOME is where the alternative system has put sun java.

<cut>

Mario, it didn't help. I installed Rssowl from generic tarball package and it 
works. I noticed that when I use open source Java + Fedora Extras' rssowl 
package that CPU jumps to 100% when I use /Tools/Discover News Feeds on a 
Website option, and it finds 0 news feeds (literally). There's no such problem 
at all when I use generic tarball package + Java Sun, and it finds news feeds.

Comment 6 Mario Torre 2006-09-23 12:18:48 UTC
Hi Igor,

Have you changed

Cipher.getInstance("Blowfish/ECB/PKCS7")

to

Cipher.getInstance("Blowfish")

and it stop worked, or has never worked (I mean, on gcj)?

In the latter case, I guess it does not belong to this bug report (this is about
making rssowl java vendor agnostic), though I can confirm your issue, but I have
a patched rssowl.

If so, I could sugget opening a new bug report.

Mario

Comment 7 Anthony Green 2007-06-22 15:01:10 UTC
rssowl was just removed due to the loss of itext.  My understanding is that
rssowl2 doesn't depend on itext, and we intend to re-introduce rssowl2 when
rawhide gets a newer SWT.  I'm closing this bug for now.