Module file parse API

Chris Hegarty chris.hegarty at oracle.com
Tue Jun 19 08:46:03 PDT 2012



On 19/06/12 09:01, Paul Sandoz wrote:
>
> On Jun 18, 2012, at 6:49 PM, chris hegarty wrote:
>
>> On 18/06/2012 17:37, Paul Sandoz wrote:
>>> On Jun 18, 2012, at 4:16 PM, Chris Hegarty wrote:
>>>>> - IIRC the complete size of the jmod file is encoded in the file itself, thus after the file header has been read we can wrap everything around a CountingInputStream.
>>>>
>>>> I really like this idea too, but I need to think carefully about the impact of concatenating some rogue module to another module file.
>>>
>>> Signed modules?
>>>
>>> Why does using a CountingInputStream over the content introduce a security issue?
>>
>> I was thinking that if the reader/installer was able to parse multiple module files from a single input stream something like this may be a problem...
>>   cat foo.jmod bar.jmod>  foo.jmod
>>   jmod install foo.jmod
>>   jmod ls
>>     foo
>>     bar
>>
>> It just means that the installer is responsible for handling this situation rather than the parser.
>>
>
> OK, i understand what you are getting at.
>
> I was not suggesting that the tooling or the parser directly support what you say above.
>
> Just suggesting something simpler: not to rule out the following capability:
>
>    InputStream s = // some stream where multiple jmods are streamed
>    while (s.available() != 0) {
>      ModuleFileParser mfp = ModuleFile.newParser(s);
>      while (parser.hasNext()) { parser.next(); }
>    }

OK, got it. I'll change the parser to support this. The Reader/Installer 
will then ensure that all bytes are read from the stream (rather than 
the parser). CountingInputStream is our friend ;-)

-Chris.

>
> Paul.



More information about the jigsaw-dev mailing list