Proposal: volunteer as a long-term maintainer

[t8y2]

Hi @aqrln, @jacek-prisma, and @luiz1361,

I'm Skyler (@t8y2), the maintainer of DBX, an open-source database client with approximately 16k GitHub stars.

DBX uses Tiberius for SQL Server support, and I recently opened #426 to address the long-standing UTF-16 issue reported in #325.

I would like to volunteer to help maintain Tiberius on a long-term basis. I can help with:

• triaging issues and stale pull requests;
• reviewing compatibility and regression fixes;
• maintaining CI and dependencies;
• preparing regular patch releases;
• providing downstream validation through DBX and real SQL Server user cases.

I am not requesting organization-wide access. A repository-scoped trial would be ideal, starting with Triage/Write or Maintain access for 60–90 days. After demonstrating consistent maintenance, we could separately discuss the release process and crates.io publishing permissions.

Would Prisma be open to this arrangement, and who would be the appropriate person to coordinate maintenance and release approvals with?

Thanks!

[MattJackson]

@t8y2 I have forked this project and am working to merge all open PRs and revive it as this repo and maintainers seem to be dead. Happy to have help.

https://github.com/MattJackson/tiberius

[SimSmith]

What do you think @t8y2? That's a lot of changes Jackson has done in a very short amount of time.

[djc]

I'm here on behalf of the RustSec working group. @north-echo filed

• Add advisory for tiberius: panics on hostile server input rustsec/advisory-db#3148

to discuss several potential DoS issues:

• Client panics instead of returning Err on unexpected server responses (7 sites in the TDS decoder) #424
• negotiated_encryption panics when the server declines the requested encryption level #425

These have so far gone unanswered, and it would be good to clarify the maintenance status of this crate. If tiberius is unmaintained (and vulnerable to issues!), it would be good to clarify that status, so we can point people at other crates and/or facilitate a handover. It looks like @MattJackson might be off to a good start (though it would be helpful if other people more conversant in the subject matter than me could have a look to validate whether their efforts are trustworthy before we recommend them).

@SevInf looks like you have contributed here and have recently contributed in other Prisma projects -- would you be able to raise this discussion internally?

[joelparkerhenderson]

Great minds think alike? I forked and published https://crates.io/crates/mssql at https://github.com/mssql-rust/mssql-rust

Claude Code triaged all the open issues and open PRs, then added most of them, with tests. @djc My day job is a large Microsoft customer and I'm asking MS to loop in their people too.

Happy to add maintainers. I'll invite @t8y2 @MattJackson @djc @north-echo now; feel free to accept if you like.

[MattJackson]

@djc Agreed, more eyes the better! I do not want to be the sole maintainer going forward, but I wanted to get it up to speed and in solid shape that others can use it today, and help build it on it tomorrow.

I love that this conversation is happening about the future of the project and am here to help as you all see fit.

[MattJackson]

@joelparkerhenderson Im just here to help the community but i think a tiberius name in the package vs rebranding as mssql is "better", people will find the new package quicker and none of the internal code changes, its just a crate update.

I will continue to maintain mine until there a clear defined path forward by the community. If a request to become a maintainer by somebody comes to me Ill gladly accept.

If this teams project wishes to transfer me the tiberius crate I will glady revert to publishing under the original name for pure simplicity vs tiberius-ng

[north-echo]

The two forks, measured against the 11 panic sites from #424 / #425

@djc asked for someone conversant in the subject matter to check whether a fork's work is sound
before RustSec points people at it. There are now two candidates, so I ran both through the same
harness rather than looking at one.

Scope. Only the 11 sites reported in
#424 and
#425. Nothing broader.

Method. The fake-server PoC used to find these originally: crafted bytes are fed as the
server's responses through a real Client::connect, so anything it reaches is reachable by a
malicious or MITM server. All runs are release builds, so debug assertions are off and nothing
here is a debug-only artifact. benign is a control that should return an error rather than panic,
and it does in every column.

Tested against the published crates.io artifacts: tiberius 0.12.3, tiberius-ng 0.13.1,
mssql 1.0.0. Building from the corresponding git trees (714bfa0, 185df10) gives identical
results.

Results

Panic locations are as reported by the panic handler, not from my notes.

case	site	tiberius 0.12.3	tiberius-ng 0.13.1	mssql 1.0.0
unknown-token	1	pre_login.rs:243	ok	ok
bad-threadid-len	2	pre_login.rs:208	ok	ok
encryption-downgrade	3	pre_login.rs:73	ok	ok
featureext-unknown	4	token_feature_ext_ack.rs:48	ok	ok
featureext-badlen	5	token_feature_ext_ack.rs:43	ok	ok
row-no-colmeta	6	token_row.rs:103	ok	ok
nbcrow-no-colmeta	7	token_row.rs:123	ok	ok
colinfo-token	8	stream/token.rs:250	ok	ok
colmeta-ssvariant	9	type_info.rs:317	ok	type_info.rs:335
colmeta-udt	9	type_info.rs:317	ok	type_info.rs:335
envchange-begintran	10	token_env_change.rs:216	ok	token_env_change.rs:216
envchange-enlistdtc	10	token_env_change.rs:216	ok	token_env_change.rs:216
benign (control)	n/a	ok	ok	ok
		12 panic	0 panic	4 panic

"ok" means the client returned an Err instead of aborting the process.

Site 11 has no case in this harness, so it is assessed from source only, below.

tiberius-ng

All 11 addressed. Counting only constructs that abort (panic!, unimplemented!,
unreachable!, todo!, bare assert!, .unwrap(), .expect()) in production code across the
seven affected files, excluding everything under #[cfg(test)]: upstream has 12, tiberius-ng has 0.

If you grep for the bare word unimplemented! you will get one hit in stream/token.rs. That is
the text inside an error message, not a panic, which is worth saying so the count is reproducible.

Two details of approach rather than outcome. Site 8 was
_ => panic!("Token {:?} unimplemented!", ty); the fork implements ColInfo properly
(TokenType::ColInfo => this.get_col_info().await?, decoding via TokenColInfo::decode) and keeps
a defensive Err fallback behind #[allow(unreachable_patterns)], rather than only silencing the
arm. Site 4 carries a regression test asserting the error
(.expect_err("unsupported feature must error")).

mssql

Eight of the 11 are fixed. Three are not, in a crate published to crates.io as 1.0.0:

• Site 9, src/tds/codec/type_info.rs:335, todo!("not yet implemented for {:?}", ty).
  Confirmed panicking. Reached by a COLMETADATA column of type 0x62 or 0xF0; the harness gets
  there, which means the crate's own type parsing accepted the byte, so a conforming server
  triggers it with nothing malformed.
• Site 10, src/tds/codec/token/token_env_change.rs:216, assert!(len == 8). Confirmed
  panicking. len is a buf.read_u8(), and this is a bare assert! rather than debug_assert!,
  so it is live in release: 255 of 256 byte values trigger it.
• Site 11, src/tds/codec/column_data/int.rs:18, unimplemented!(). Present in source. The
  harness has no case for it, so unlike the two above this is not verified by execution here.

Sites 10 and 11 are at the same line numbers as upstream. Site 9 has moved (317 to 335), so that
file has been edited, just not at this arm.

There is a fourth aborting construct in mssql, type_info.rs:120
todo!("encoding {:?} is not supported yet"), which is also in upstream at line 102. It is on the
encode path rather than the server-input path, so it was never part of my report and I make no
claim about it.

What this does not cover

The reported sites only. This is not a claim that either fork is free of other panics, and I have
not re-fuzzed either. It says nothing about provenance, release process, or long-term maintenance
capacity, which are separate questions from the one asked and matter just as much for a
recommendation.

Bearing on the advisory

rustsec/advisory-db#3148 carries patched = [] because no fixed release existed. On these sites
tiberius-ng 0.13.1 is one. mssql 1.0.0 is not yet, so if it were recommended as-is, users upgrading
away from the advisory would still be exposed to sites 9, 10 and 11.

Happy to share the PoC with either maintainer.

---

Assisted-by: Claude (claude-opus-5): test execution and write-up. The PoC and the original
findings in #424 / #425 are my own prior work. Everything above is reproducible: the harness cases
are named, the panic locations are as emitted by the panic handler on release builds, and the runs
are against the published crates.io artifacts.

[MattJackson]

@north-echo great analysis, thank you.

[joelparkerhenderson]

@north-echo Likewise, thank you. I'm releasing 1.0.1 now. Are you able to run your harness on it? And/or if you would like to provide your harness, I can pop it into CI.

@MattJackson Yes your naming sounds reasonable to me for what you're describing, whereas I'm working with new users who know the word mssql and don't know the tiberius project.

[north-echo]

@joelparkerhenderson Ran the harness against mssql 1.0.1 from crates.io, release build. All 12
hostile cases now return an Err instead of aborting, including the four that panicked on 1.0.0:

case	site	1.0.0	1.0.1
colmeta-ssvariant	9	panic, type_info.rs:335	Err(Protocol)
colmeta-udt	9	panic, type_info.rs:335	Err(Protocol)
envchange-begintran	10	panic, token_env_change.rs:216	Err(Protocol)
envchange-enlistdtc	10	panic, token_env_change.rs:216	Err(Protocol)

Site 11 has no case in my harness, so I checked the published 1.0.1 source instead: it is fixed
too, column_data/int.rs now returns Err(Error::Protocol("intn: length of {} is invalid"))
rather than unimplemented!().

So all 11 sites from #424 / #425 are closed in 1.0.1, same as tiberius-ng 0.13.1.

One aborting construct is left in that file set, type_info.rs:120,
todo!("encoding {:?} is not supported yet"). It is on the encode path rather than the
server-input path, it is present in upstream too, and it was never part of my report, so treat that
as an observation rather than a finding.

Yes on CI, happy to. It is a small standalone binary and needs no test server: it binds a loopback
TcpListener, the fake server accepts, reads the client's PRELOGIN and writes a crafted TDS
response, and a real tiberius::Client::connect runs against that over TcpStream. One named case
per site, and the assertion is just "returns Err rather than aborting the process", with a
benign case as the control. I will send the same to @MattJackson so both projects have it.

One thing worth saying out loud rather than deciding quietly: these cases still reproduce against
published tiberius 0.12.3, which is unfixed and at 667K downloads per 90 days, so putting them in
a public CI is effectively publishing a working reproducer. I think that is net positive here,
because #424 lists every trigger in a table already, the advisory PR is public, and there are now
two patched continuations to move to. Flagging it so the choice is made deliberately.

---

Assisted-by: Claude (claude-opus-5): test execution and write-up. Runs are against the published
crates.io artifact in a release build; panic locations quoted are as emitted by the panic handler.

[SevInf]

Hi everyone, sorry for late response, ping got lost in my emails. I'll raise issue internally if you still want to have canonical name. No promises, but my gut feeling is that we'll be able to hand it over with no problem.