Develop Reference

bouncycastle throws exception when file contains a mix of secret and public keys

I am running this code:
public static void main(String[] args) throws IOException, PGPException {
InputStream privateKeyRings = new FileInputStream("/path/to/file/secring.gpg");
PGPSecretKeyRingCollection pgpSecretKeyRings =
new PGPSecretKeyRingCollection(PGPUtil.getDecoderStream(privateKeyRings), new JcaKeyFingerprintCalculator());
}
And I get this error:
Exception in thread "main" org.bouncycastle.openpgp.PGPException: org.bouncycastle.openpgp.PGPPublicKeyRing found where PGPSecretKeyRing expected
at org.bouncycastle.openpgp.PGPSecretKeyRingCollection.<init>(Unknown Source)
at test.main(test.java:36)
Therefor I inspected the file secring.gpg by running
gpg --show-keys --no-default-keyring secring.gpg
Which gives me a list of keys
sec# rsa4096 2013-02-21 [SC]
37B...
uid xyz <xyz#xyz.com>
ssb# rsa4096 2013-02-21 [E]
sec# rsa4096 2013-02-14 [SC]
22C...
uid abc <abc#abc.com>
ssb# rsa4096 2013-02-14 [E]
pub rsa4096 2013-04-19 [SC]
5A1...
uid def <def#def.com>
sub rsa4096 2013-04-19 [E]
So as far as I can tell, the file contains secret keys, except for the last entry which seems to be a public key.
So my guess is that this is causing the error.
What is the best way to avoid the error?
Do I need to remove the public key from the file secring.gpg? If so, what is the command for this?
And is there another way to handle this scenario in the java code?

Yes that class supports only secret key 'rings' (note what Bouncy calls a 'keyring' is what GnuPG just calls a key, and what GnuPg calls a keyring is what Bouncy calls a 'collection').
I think the best way is indeed to fix the file. That file name secring.gpg was used by older versions of GnuPG for a file in OpenPGP format that contained only secret keys, not public, so whoever created that file either did something really weird and wrong or was trying to mislead and harm people. I don't think there ever was a command that could fix a public key in secring because that wasn't supposed to happen in the first place. In any case modern GnuPG no longer uses that file; it now uses a directory containing separate files in a libgcrypt-based format.
What you could do is use GnuPG to --import this file (import can handle both secret and public keys, because interchange can in various cases use either) and then --export-secret-keys the desired ones. If you set env var GNUPGHOME to a new (empty) directory and import to that, you can simply export everything valid from that directory and then delete it.
Alternatively you could write your own class which is like PGPSecretKeyRingCollection but ignores (skips) any PGPPublicKeyRing object(s). If the rest of your code, or any code you call to use this data, only uses the behavior of PGPSecretKeyRingCollection and doesn't depend on internals or exact identity -- which by OO doctrine it shouldn't -- you can just substitute your object. In older Java you can even extends the real class, so that it can be stored in variables etc. declared with the real type, but with recent Java (9 up) I think subclassing across modules is restricted and this may require --add-opens or somesuch -- I haven't looked into that area yet.
More ambitiously, Bouncy is opensource, so you could fork it and make this change, and any others you want. Of course you would need to set up a complete build environment for it, and periodically take at least the upstream changes that either provide new features you need or want or are security fixes -- in practice it's almost certainly easier to take all changes, and if something conflicts cross that bridge when you get to it.

Check if plugin used "compile files" when it should've used "provided"

Little background for context:
The application I support allows third parties to develop plugins that can leverage some of our functionality. We hand them our "externalAPI.jar"; they put it in their project, implement some interfaces, and build their own APK. We find the would-be plugin by asking the package manager for all installed applications and see if each has a "pluginclass.xml" in the assets directory. If it has that XML file, we anticipate its contents being the canonical path of a class that implements our ExternalPluginVX interface, and using a new PathClassLoader(ApplicationInfo.sourceDir, this.getClass().getClassLoader()), we load the class, create a new instance, and start using it.
The problem:
Sometimes third parties will put
compile files ("./libs/externalAPI.jar")
in their gradle files instead of the correct syntax:
provided files ("./libs/externalAPI.jar")
The result of course being things don't work properly. Sometimes they almost work, but then have unpredictability in their behavior - usually involving vicious crashes. Notably, since their APK is well-formed in its own right, and the XML file is there, we'll see the plugin, load the target class successfully, instantiate it successfully, and things go haywire from there when they try and reference back to us.
The question:
Is there a way for my application to check at runtime if the other application compiled our API classes into their APK instead of using provided files like they should have?

A viable solution is to use a DexFile.
Since I already have the ApplicationInfo.sourceDir, I can just construct a DexFile and iterate through its contents.
//this variable's value assigned by iterating through context.getPackageManager().getInstalledApplications(0)
ApplicationInfo pkg;
String interfaceTheyShouldntHave = ExternalPluginVX.class.getCanonicalName(); //"com.project.external.ExternalPluginVX"
DexFile dexFile = new DexFile(pkg.sourceDir);
Enumeration<String> entries = dexFile.entries();
while(entries.hasMoreElements()){
String entry = entries.nextElement();
if(entry.equals(interfaceTheyShouldntHave)){
Toast.makeText(ctxt, "Plugin \"" + pluginName + "\" could not be loaded. Please use 'provided files' instead of 'compile files'", Toast.LENGTH_LONG).show();
return;
}
}

creating directory from Java on a shared location

I can't seem to figure out why I can't create a directory from a Java program FOR A SPECIFIC LOCATION.
The specifics are - the folder of my computer is shared on the network.
Code:
File xmlDirectory = new File(sXMLOutputPath);
/*
* TODO: if multiple threads arive at the 1st if, if will evaluate to true,
* then 1st thread would create directory, and the 2nd being .01 sec later, will fail
* to create directory and have exception
* SOLUTION: Provide additional if exists, so that 2nd thread will recognize that it
* was created.
*/
if (!xmlDirectory.exists()){
if (!xmlDirectory.mkdirs()){
if (!xmlDirectory.exists()){
throw new BillAdminException("Failed to create xml directory: " +
sXMLOutputPath);
}
}
}
This is a server side code
In summary - if I share my foder C:\folder\etc - and pass it as JVM options to the program, the server side program "appends" \xml\333\333.xml" to it, and is supposed to create that xml file on MY PC. First it creates a structire C:\folder\etc\xml\333\, and then it creates 333.xml. It fails creating C:\folder\etc\xml\333 if the C:\folder\etc is passed as shared location in the form "\myMachine\etc", but works OK if I make that structure on some other machine "\OtherMachine\etc". If I pass it as "C:\folder\etc" (absolute, not shared form) it will work fine, creating directory and file on the server machine where code is executed. I need it created on my machine (client). What am I doing wrong when sharing folder.
P.S - this functionality worked about 2 month ago. However, the folder properties could have been tempered with since then. Not the java code, though.
P.S 2: this is not the only shared folder I pass from JVM options. There are 2 others, but used for reading (not creating subfolders)
Thanks, for help
P.S 3: The error I get is:
Failed to create xml directory: \\myMachine\etc\xml/333/
What I smell fishy, is that the slash before "333" is reversed. But, there were no changes in the code, so the same would have been happening before.

Java 1.4.2 File.listFiles not working properly with CIFS mounts - workaround?

I'm using Java 1.4.2 and Debian 6.0.3. There's a shared Windows folder in the network, which is correctly mounted to /mnt/share/ via fstab (e.g. it's fully visible from OS and allows all operations) using CIFS. However, when I try to do this in Java:
System.out.println(new File("/mnt/share/").listFiles().length)
it would always return 0, meaning File[] returned by listFiles is empty. The same problem applies to every subdirectory of /mnt/share/. list returns empty array as well. Amusingly enough, other File functions like "create", "isDirectory" or even "delete" work fine. Directories mounted from USB flash drive (fat32) also work fine.
I tested this on 2 different "shared folders" from different Windows systems; one using domain-based authentication system, another using "simple sharing" - that is, guest access. The situation seems weird, since mounted directories should become a part of a file system, so any program could use it. Or so I thought, at least.
I want to delete a directory in my program, and I currently see no other way of doing it except recursive walking on listFiles, so this bug becomes rather annoying. The only "workaround" I could think of is to somehow run an external bash script, but it seems like a terrible solution.
Edit: It seems this is 1.4.2-specific bug, everything works fine in Java 6. But I can't migrate, so the problem remains.
Could you suggest some workaround? Preferably without switching to third-party libs instead of native ones, I can't say I like the idea of rewriting the whole project for the sake of single code line.

Since Java 1.2 there is method File.getCanonicalFile(). In your case with mounted directory you should use exactly this one in such style:
new File("/mnt/share/").getCanonicalFile().listFiles()

So, two and half years later after giving up I encounter the same problem, again stuck with 1.4.2 because I need to embed the code into obsolete Oracle Forms 10g version.
If someone, by chance, stumbles onto this problem and decides to solve it properly, not hack his way through, it most probably has to do with (highly) unusual inode mapping that CIFS does upon mounting the remote filesystem, causing more obscure bugs some of which can be found on serverfault. One of the side-effects of such mapping is that all directories have zero hard-link count. Another one is that all directories have "size" of exactly 0, instead of usual "sector size or more", which can be checked even with ls.
I can't be sure without examining the (proprietary) source code, but I can guess that Java prior to 1.5 used some shortcut like checking link count internally instead of actually calling readdir() with C, which works equally well for any mounted FS.
Anyway, the second side-effect can be used to create a simple wrapper around File which won't rely on system calls unless it suspects a directory is mounted using CIFS. Other versions of list and listFiles functions in java.io.File, even ones using filters, rely on list() internally, so it's OK to override only it.
I didn't care about listFiles returning File[] not FileEx[] so I didn't bother to override it, but is should be simple enough. Obviously, that code can work only in Unix-like systems having ls command handy.
package FSTest;
import java.io.BufferedReader;
import java.io.File;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.ArrayList;
public class FileEx extends File
{
public FileEx(String path)
{
super(path);
}
public FileEx(File f)
{
super(f.getAbsolutePath());
}
public String[] list()
{
if (this.canRead() && this.isDirectory())
{
/*
* Checking the length of dir is not the most reliable way to distinguish CIFS mounts.
* However, zero directory length generally indicates something unusual,
* so calling ls on it wouldn't hurt. Ordinary directories don't suffer any overhead this way.
* If this "zero-size" behavior is ever changed by CIFS but list() still won't work,
* it will be safer to call super.list() first and call this.listUsingExec if returned array has 0 elements.
* Though it might have serious performance implications, of course.
*/
if (this.length() > 0)
return super.list();
else
return this.listUsingExec();
}
else
return null;
}
private String[] listUsingExec()
{
Process p;
String command = "/bin/ls -1a " + this.getAbsolutePath();
ArrayList list = new ArrayList();
try
{
p = Runtime.getRuntime().exec(command);
p.waitFor();
BufferedReader reader = new BufferedReader(new InputStreamReader(p.getInputStream()));
for (String line = reader.readLine(); line != null; line = reader.readLine())
{
if (!line.equalsIgnoreCase(".") && !line.equalsIgnoreCase(".."))
list.add(line);
}
String[] ret = new String[list.size()];
list.toArray(ret);
return ret;
}
catch (IOException e)
{
return null;
}
}
}

Make JAR as a standalone executable

Is there a way to convert JAR lib into JAR standalone?
I need to find a standalone java executable that convert PDF into TIFF and I've found these JARs: http://www.icefaces.org/JForum/posts/list/17504.page
Any ideas?

Easiest might be to create another Jar with a Main() entry point, and then just use the java.exe executable to run it:
e.g.
> java.exe -cp MyJarMain.jar;MyPDFJar.jar com.mydomain.MyMain myPDF.pdf
Where MyMain is a class with a Main static method.
You'll need something with a main entry point to pass in and interpret some command line arguments (myPDF.pdf in my made-up example)

You could do an assembly (are you using maven?) and make sure the Main-Class entry in the manifest.mf points to the main class.

Since there is no main-Method, you have to write one, or write a whole new class to call the class/method TiffConver.convertPDF .
The question is, how you're going to use it. From the command line, you need no executable jar. From the Gui, maybe you want to pass a file to be converted by drag and drop? Then you should take the parameter(s) passed to main as Input-PDF-Names (if they end in .pdf) and pass the names iteratively to TiffConverter, for "a.pdf b.pdf" =>
TiffConver.convertPDF ("a.pdf", "a.tiff");
TiffConver.convertPDF ("b.pdf", "b.tiff");
TiffCoverter will silently overwrite existing tiffs, so check that before or change the code there - this is clearly bad habit, and look out for more such things - I didn't.
/*
* Remove target file if exists
*/
File f = new File(tif);
if (f.exists()) {
f.delete();
}
Maybe you wan't to write a swing-wrapper, which let's you choose Files interactively to be converted. This would be a nice idee, if no filename is given.
If the user passes "a.pdf xy.tiff" you could rename the converted file to xy, as additional feature.
Without a main-class, however, a standalone jar would be magic.
However, building a native executale is almost always a bad idea. You loose portability, you don't profit from security- and performance improvements to the JVM or fixed bugs. For multiple programs you need always an independend bugfix, which you might have to manage yourself, if you don't have a package-management as most linux distros have.
after clearing some questions:
public static void main (String [] args) {
if (args.length == 1 && args[0].endsWith (".pdf")) {
String target = args[0].replaceAll (".pdf$", ".tif");
convertPDF (args[0], target);
}
}
This method you put into TiffConvert. It will allow you to convert a simple pdf-File, and generate a tif-File with the same basename but ending in .tif, silently overwriting an existing one of the same name.
I guess you now need to know how to start it?