Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Version number parsing in GDSServerVersion and AbstractFbDatabase (and GDS for earlier versions) is incorrect [JDBC535] #568

Closed
firebird-automations opened this issue Jun 6, 2018 · 5 comments

Comments

@firebird-automations
Copy link

Submitted by: @mrotteveel

The version number parsing done on the value returned by isc_info_firebird_version is wrong. The implementation assumes the returned value is a single string, but apparently it is a compound binary response that consists of multiple length prefixed segments. This causes issues with parsing, like - for example - JDBC152 and others.

As it turns out, historically what we thought was a separator in the version string (either ",", "-" or "/"), was actually a length byte in the string that on our systems just happened to look like a separator because our hostnames had length 6 which made the extended version string either 44(,), 45(-) or 47(/) bytes.

Commits: a483426 ef1fedc 0bccd74

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

Fix Version: Jaybird 2.2.15 [ 10860 ]

Fix Version: Jaybird 3.0.5 [ 10873 ]

Fix Version: Jaybird 4 [ 10441 ]

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

description: The version number parsing done on the value returned by isc_info_firebird_version is wrong. The implementation assumes the returned value is a single string, but apparently it is a compound binary response that consists of multiple length prefixed segments. This causes issues with parsing, like - for example - JDBC152 and others.

As it turns out, historically what we thought was a separator in the version string (either ",", "-" or "/"), was actually a length by in the string that on our systems just happened to look like a separator because our hostnames had length 6 which made the extended version string either 44(,), 45(-) or 47(/) bytes.

=>

The version number parsing done on the value returned by isc_info_firebird_version is wrong. The implementation assumes the returned value is a single string, but apparently it is a compound binary response that consists of multiple length prefixed segments. This causes issues with parsing, like - for example - JDBC152 and others.

As it turns out, historically what we thought was a separator in the version string (either ",", "-" or "/"), was actually a length byte in the string that on our systems just happened to look like a separator because our hostnames had length 6 which made the extended version string either 44(,), 45(-) or 47(/) bytes.

@firebird-automations
Copy link
Author

Commented by: @mrotteveel

Committed fix that will read the version in segments

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

status: Resolved [ 5 ] => Closed [ 6 ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment