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

[Jiri Vanek]

On 03/02/2015 03:21 PM, Jacob Wisor wrote:
> 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?
Half of them. It would be more complex change if only the signed ones should be enhanced.
as name in unsigned one do not hart, I would vote for add it to all.

 > Does IcedTea-Web issue
> warnings on signed JARs only?
> If IcedTea-Web is /always/ warning then IcedTea-Web itself should probably be fixed first.

Unluckily yes it is. Because it is a bit tricky to make the signed check on place where getTitle is 
used...
The other checks on manifest attributes are using "action only if signed RIA" properly.
>
> 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.

I agree 100% with you. As another disadvantage, user is facing more poups:(

Luckily, ITW have possibility to disable manifest check completly, or half of them on low security 
settings.

J.