Hi Cole. In this concrete case, I suppose that it would be enough to provide a password not as a property but as a lambda that then reads the password on demand from a secure location.
On Sat, Jan 17, 2026 at 2:14 AM Cole Greer <[email protected]> wrote: > Hi Andrii, > > I would agree it is essential that we follow industry best practices with > regards to security. Do you have any suggestions on how you'd like to > address the password in the heap issue? > > I'm certainly no expert in this domain. Upon initial investigation, I'm > finding plenty of discussions over storing passwords as String vs char[] > (which may warrant consideration), however I'm not finding any consensus on > avoiding passwords in the JVM heap. > > I'm open to any suggestions which improve driver security and don't > unreasonably impede the user experience. > > Regards, > Cole > > On 2026/01/16 08:03:43 Andrii Lomakin via dev wrote: > > Dear TP Team, > > > > I have identified a potential security issue regarding the standard TP > > driver module. Currently, the module retains user passwords in the JVM > heap > > for the duration of its lifecycle. > > > > This poses a risk as any heap dump, such as those caused by an Out Of > > Memory (OOM) error, could expose sensitive user credentials to the DevOps > > team or anyone with access to the dump. > > > > I believe we should address this to ensure more secure handling of > > passwords. > > > > Best regards, > > -- > > Andrii Lomakin > > YouTrackDB development lead > > > -- Andrii Lomakin YouTrackDB development lead
