Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #36554 > unrolled thread

Re: Breaking JNLP apps

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Breaking JNLP apps Andreas Leitgeb <avl@logic.at> - 2017-04-29 00:11 +0000
    Re: Breaking JNLP apps Andreas Leitgeb <avl@logic.at> - 2017-05-02 18:23 +0000

#36554 — Re: Breaking JNLP apps

markspace <markspace@nospam.nospam> wrote:
> On 4/6/2014 1:07 PM, Andreas Leitgeb wrote:
>> I recently posted here about my jnlp-template problems, but either
>> no one saw it or no one knew an answer. No one was inclined to post
>> a followup. The post's subject was
>>    "difficulties with using signed jnlp template"
>> its message-id is: <slrnlf9tf8.ngg.avl@gamma.logic.tuwien.ac.at>
> Here's a blog from Oracle I just happened on.  I wonder if you could 
> leave a comment or use their community features to get feedback on the 
> issue you're having.
> <https://blogs.oracle.com/java-platform-group/entry/new_security_requirements_for_rias>

Ok now, about 3 years later, I've finally been making some progress. I did
get the app running on an 1.8.0_131 client, but face some restrictions,
which (if I can't solve them) would complicate the deployment quite a bit.

The problem is about the jnlp-templates: I can successfully replace *some*
parts like the <jnlp codebase="..."> or <title>...</title> value with a *,
but if I try to use wildcards for a custom property:
    <property name="jnlp.myapp.foo" value="*"/>
in the <resources> section, then the signature verification fails, no
matter what was the actual value in the downloaded myapp.jnlp. (Even,
if it had a literal "*" there thus being equal to the template!)

The question is: how can I freely parameterize aspects of the application
without needing to embed the exact parameterization into the main jar file
and w/o the need to produce a specific signed jar for each possible set of
parameterizations?

Are there other parts of the jnlp more suitable for passing strings to the
app than properties?

Thanks in advance.


PS: the linked page claims the following:

" Some developers may notice that the <security /> element is missing from
" the above JNLP. By providing it within the cryptographically signed JAR
" file, it is no longer necessary within the JNLP for Java 7 update 51
" (January 2014).

This appears to be no longer true with 1.8 (or wasn't ever true to begin
with), as the application kept failing with some misleading error(*), until
I added the <security>...</security> tags back into the jnlp file to match
the Manifest's "Permissions:" entry.    (*): no java console, no exception
text - some dialog popped up suggesting to check the control panel...

[toc] | [next] | [standalone]

#36577

Andreas Leitgeb <avl@logic.at> wrote:
> Ok now, about 3 years later, I've finally been making some progress. I did
> get the app running on an 1.8.0_131 client, but face some restrictions,
> which (if I can't solve them) would complicate the deployment quite a bit.
>
> The problem is about the jnlp-templates: I can successfully replace *some*
> parts like the <jnlp codebase="..."> or <title>...</title> value with a *,
> but if I try to use wildcards for a custom property:
>     <property name="jnlp.myapp.foo" value="*"/>
> in the <resources> section, then the signature verification fails, no
> matter what was the actual value in the downloaded myapp.jnlp. (even,
> if it had a literal "*" there thus being equal to the template!)

I think, I found the relevant (though vague) "documentation" of my 
observations in the jnlp specification (Section 5.4.1):

" The template (APPLICATION_TEMPLATE.JNLP) may have fields for CDATA
" arguments or values denoted as "*".   [...]  An element value or
" attribute value matches if either the value in the template is
" identical to the value in the JNLP file used to launch the app,

Well, that isn't true, because it didn't even accept "*" in the 
downloaded jnlp where the template had "*" for some property's value.

" or all of the following are true:
" - [...] of type CDATA [...] or #PCDATA
" - [...] value in the signed template is "*"
" - [...] value is not blacklisted or restricted by the JNLP Client

" It is expected that a JNLP Client will blacklist [...] jnlp elements
" and argument values such as "java-vm-args" or property "name" and "value" 

Given that properties already have to start with "jnlp." (or "javaws.")
to be even definable in the jnlp file, and the template is signed in
the jar file (thus noone can cheat a "*" into the template that the
author didn't expect), then this restriction makes zero sense.


I've also found other resources on the net dealing with similar
problems, like e.g.:
http://stackoverflow.com/questions/19883525/wildcards-in-jnlp-template-file
which only complains about * not being able to match nested <argument>
tags, but doesn't seem to have problems with "*" values for properties.
That's 4 years ago; seems like 1.8.0's Jnlp-client has become even more
restrictive, since.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web