<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Aptos;
panose-1:2 11 0 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:12.0pt;
font-family:"Aptos",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Aptos",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">Hi Chen,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Internally it is already resolved, and it does not bring much of a value to change only internal implementation.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">I'm OK with the proposed API addition, however real use cases would give the proposal more weight.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Priority is to clean the Class-File API and additions to the API should be backed by real use cases or visible benefits in the existing code.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Procedurally, feel free to go ahead and propose it to 23.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Adam<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div id="mail-editor-reference-message-container">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="color:black">From:
</span></b><span style="color:black">Chen Liang <liangchenblue@gmail.com><br>
<b>Date: </b>Tuesday, 21 May 2024 at 13:54<br>
<b>To: </b>classfile-api-dev <classfile-api-dev@openjdk.org>, asotona@openjdk.org <asotona@openjdk.org><br>
<b>Subject: </b>Re: Type-checked entryByIndex and readEntryOrNull<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal">Hi Adam,<o:p></o:p></p>
<div>
<p class="MsoNormal">This patch is simple; since this can prevent a lot of bugs around malicious CP references in crafted classfiles, should we consider this enhancement for JDK 23, or should we only have this as internal APIs in ClassReaderImpl?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">- Chen<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Mon, May 20, 2024 at 9:08<span style="font-family:"Arial",sans-serif"> </span>AM - <<a href="mailto:liangchenblue@gmail.com" target="_blank">liangchenblue@gmail.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">Hi ClassFile API list,<o:p></o:p></p>
<div>
<p class="MsoNormal">I call for addition of a type-checked entryByIndex in ConstantPool, with a signature:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><T extends PoolEntry> T entryByIndex(int index, Class<T> cls)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">and a type-checked readEntryOrNull in ClassReader, with a signature:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><T extends PoolEntry> T readEntryOrNull(int offset, Class<T> cls)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Which will throw ConstantPoolException if the entry is of a mismatched type, much like the type-checked readClassEntry in ClassBuilder.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">A search for existing generic ConstantPool::entryByIndex and ClassReader::readEntryOrNull in JDK reveals that most of their usages within the jdk.internal.classfile.impl and its subpackages involve a direct cast right after retrieving the
result. These casts are susceptible to malformed classfiles putting entries of wrong type, such as a Utf8 at the cursor of superclass entry, throwing ClassCastException, which is out of spec with the Classfile API.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I recommend adding these 2 methods for user convenience, and migrating all existing entryByIndex/readEntryOrNull with casts to these 2 new methods, to enhance the robustness of the ClassFile API. (On a side note, we can promote ClassReader::utf8EntryByIndex
to ConstantPool too)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Please feel free to comment or critique this proposal.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Chen Liang<o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</body>
</html>