[rfc][icedtea-web] add application name to all manifests

[Jacob Wisor]

On 03/02/2015 12:50 PM, Jiri Vanek wrote:
> On 02/28/2015 01:42 AM, Jacob Wisor wrote:
>> On 02/27/2015 02:43 PM, Jiri Vanek wrote:
>>> This is adding Application-Name to all jars' manifests in our reproducres suite.
>>>
>>> If the A-N exists in manifest or input Manifest file exists, then A-N is not
>>> added into manifest(may be reproducer relying on that)
>>>
>>> As A-N is moreove mandatoryattribute, I added it also to amnual testcases with
>>> custom manifest, as they donot relay oon it.
>>>
>>> J.
>>>
>>> Later I would like to include it also to 1.5
>>
>> Hmm, Application-Name? I just looked over the JAR File Specification and did
>> not find this header
>> specified. I am sorry if I am missing something here but I do not get the
>> reason why this header
>> needs to be included. Well, on the other hand the Java manifest parser has
>> been tolerant of
>> non-specification headers so far. This might change since the specification
>> does not mention
>> anything about user-defined headers.
>>
>> Long story short, can you please explain the Application-Name header?
>>
>
> Yup.
>
> It came from here:
> http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/manifest.html

Oh OK, I get it now. Thanx!

>  From those are also two Trusted-Only Attribute and Trusted-Library Attribute
> which are missing in ITW.
>
>
> "If the Application-Name attribute is not present in the JAR file manifest, a
> warning is written ... "
>
> When we implemented  Application-Name we printed it also to stdout/err. Now
> reproducers are spamming "No Application-Name found in manifest"
>
> Thats my point...

As I understand, warnings about a missing Application-Name attribute are 
supposed to be issued only on *signed* applets and/or JNLP applications. Are the 
test JARs signed? Does IcedTea-Web issue warnings on signed JARs only?
If IcedTea-Web is /always/ warning then IcedTea-Web itself should probably be 
fixed first.

Anyway, the Codebase and Application-Library-Allowable-Codebase attributes seem 
strange to me from a conceptional point of view. This reads to me more like a 
helpless attempt to implement DRM on online deployed JARs. Anyone can still 
re-author a JAR's manifest with his/her own codebases and then re-sign it 
anyway. This does not improve security a bit. It is really not that hard to get 
a certificate from a common large code signing CA, so re-signed applets and JNLP 
applications will still pass the user's attention unnoticed.

Regards,

Jacob