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-issue-importer opened this issue Jun 6, 2018 · 5 comments

Comments

@firebird-issue-importer
Copy link

@firebird-issue-importer firebird-issue-importer commented Jun 6, 2018

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-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jun 6, 2018

Modified by: @mrotteveel

Fix Version: Jaybird 2.2.15 [ 10860 ]

Fix Version: Jaybird 3.0.5 [ 10873 ]

Fix Version: Jaybird 4 [ 10441 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jun 6, 2018

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-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jun 9, 2018

Commented by: @mrotteveel

Committed fix that will read the version in segments

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jun 9, 2018

Modified by: @mrotteveel

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

resolution: Fixed [ 1 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Sep 7, 2018

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