makssent opened a new pull request, #40188:
URL: https://github.com/apache/shardingsphere/pull/40188
Changes proposed in this pull request:
- `FirebirdAcceptDataPacket` now pads the SRP data of `op_accept_data`
(salt length, salt, key length, public key) with zeros to a multiple of 4 bytes
with the new `FirebirdPacketPayload#writePadding`.
- `op_accept_data` is written by
[Firebird](https://github.com/FirebirdSQL/firebird/blob/v5.0.4/src/remote/protocol.cpp#L367-L378)
and read by
[Jaybird](https://github.com/FirebirdSQL/jaybird/blob/v6.0.6/src/main/org/firebirdsql/gds/ng/wire/WireConnection.java#L452-L462).
- `p_acpt_data` is padded with zeros to a multiple of 4 bytes by
[Firebird](https://github.com/FirebirdSQL/firebird/blob/v5.0.4/src/remote/protocol.cpp#L1421-L1430).
- `FirebirdPacketPayload#writeBuffer`, `FirebirdGenericResponsePacket` and
`FirebirdFetchResponsePacket` now also write their XDR padding with
`writePadding` instead of computing `(4 - length) & 3` in place. The bytes they
write do not change.
- Previously, when the random SRP public key of the proxy had a leading
zero byte, which the proxy drops from its hex text (about 1 connection in 230),
the SRP data was 290 bytes long, and the proxy wrote `p_acpt_plugin` right
after it without the 2 padding bytes. The client waited for the rest of
`op_accept_data` until its read timeout and failed with `isc_network_error`, or
forever without a timeout. Now the proxy pads the data as the Firebird server
does (`op_accept_data` with `p_acpt_data` padded to a multiple of 4 bytes).
<details>
<summary>Verification</summary>
The same protocol packets were executed directly against a real database and
through the proxy, and the results were compared.
* Server: Firebird 5.0
* Clients: Jaybird 5.0.13 and 6.0.6
`op_connect` as Jaybird writes it is sent 1000 times on new connections,
and each answer is read up to the plugin name after `p_acpt_data`. Then Jaybird
logs in 200 times with a read timeout of 15 s. Each cell shows the runs with
both clients as `Jaybird 5 / Jaybird 6`. The numbers before the fix change from
run to run, because the proxy generates a random SRP key for each connection.
Before the fix:
| Packet | Proxy | Server | Match |
|---|---|---|---|
| `op_connect` 1000 times, answers without padding after `p_acpt_data` | 4
/ 4 | 0 / 0 | no |
| `op_connect` 1000 times, no readable `op_accept_data` | 0 / 0 | 0 / 0 |
yes |
| Jaybird logs in 200 times, failed logins | 2 / 1 | 0 / 0 | no |
After the fix:
| Packet | Proxy | Server | Match |
|---|---|---|---|
| `op_connect` 1000 times, answers without padding after `p_acpt_data` | 0
/ 0 | 0 / 0 | yes |
| `op_connect` 1000 times, no readable `op_accept_data` | 0 / 0 | 0 / 0 |
yes |
| Jaybird logs in 200 times, failed logins | 0 / 0 | 0 / 0 | yes |
The other uses of `writePadding` do not change the bytes on the wire. The
whole protocol test suite of the proxy (178 runs with Jaybird 5.0.13, Jaybird
6.0.7 and raw packets) gives the same result and output before and after them.
</details>
---
Before committing this PR, I'm sure that I have checked the following
options:
- [x] My code follows the [code of
conduct](https://shardingsphere.apache.org/community/en/involved/conduct/code/)
of this project.
- [x] I have self-reviewed the commit code.
- [ ] I have (or in comment I request) added corresponding labels for the
pull request.
- [ ] I have passed maven check locally : `./mvnw clean install -B -T1C
-Dmaven.javadoc.skip -Dmaven.jacoco.skip -e`.
- [ ] I have made corresponding changes to the documentation.
- [x] I have added corresponding unit tests for my changes.
- [ ] I have updated the Release Notes of the current development version.
For more details, see [Update Release
Note](https://shardingsphere.apache.org/community/en/involved/contribute/contributor/)
- [ ] I have specified the tool and the affected files or area for
substantial AI assistance, as required by the [AI-assisted contribution policy].
[AI-assisted contribution policy]:
https://github.com/apache/shardingsphere/blob/master/AI_POLICY.md
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
