RDF Patch Binary Reader silently accepts some invalid patch files
- Dominant language
- Java
- Stars
- 1.4k
- Forks
- 712
- Avg merge
- 15h 41m
- Merged PRs (30d)
- 53
Description
### Version
5.0.0
### What happened?
Consider the following test case:
```java
protected RDFPatch read(InputStream in) {
return RDFPatchOps.readBinary(in);
}
@Test
public void junk_01() {
byte[] junkData = "junk".getBytes(StandardCharsets.UTF_8);
RDFPatch patch = read(new ByteArrayInputStream(junkData));
Assert.fail("Malformed binary stream should throw an error");
}
```
Since the input is not a patch in RDF Thrift format it would be expected that an error would be thrown. Instead an empty patch is returned and the error is silently ignored.
This bit of the code seems relevant:
```java
try { row.read(protocol) ; }
catch (TTransportException e) {
if ( e.getType() == TTransportException.END_OF_FILE )
break;
throw new PatchException("Thrift exception", e);
}
```
It seems like it always treats an EOF as an acceptable error, irregardless of whether the input was genuinely at EOF or EOF was simply encountered due to malformed/incomplete data.
### Relevant output and stacktrace
_No response_
### Are you interested in making a pull request?
Maybe
Contributor guide
Research direction
Start with RDFPatchOps.readBinary and the row.read(protocol) EOF handling shown in the report, then locate the associated binary-reader tests. Reproduce the junk input case and compare it with a valid patch ending at EOF; done means malformed or incomplete input raises an error while a genuinely completed stream remains accepted.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- data
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100