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