Allow user to choose more time for locking after inactivity

[grenzor]

Expected Behavior

You should be allowed to go higher than 9999 seconds (like Keepass does) before the database locks itself after inactivity as this number can be short depending on different people's wants.

Current Behavior

The maximum time XC can go without locking is 9999 seconds (~2.5hrs) which is too quick for my uses.

[droidmonkey]

Quite frankly 2.5 hours is totally outright for this feature as well. Just because you can do it, doesn't mean you should. Why even turn on autolock if you want to keep the database open for so long? If you are storing passwords that is very insecure by any stretch.

[grenzor]

It can be insecure and I know very well the attacks that can happen if the database is left too long but for my use case I'm fine with it and it would be more convenient if it were possible to set a longer time so I don't need to keep reopening my database multiple times to use XC during my computer sessions.

[droidmonkey]

I ask again why don't you just disable autolock entirely and lock it manually when you are done?

[grenzor]

I did that before, but I'm forgetful and don't always know when I'm completely finished using the computer and can forgot locking at the end from time to time. At least with auto locking after a certain time is past I can be certain that it will be closed.

[nanomader]

Option to (save? and) lock database after X minutes of inactivity. And it should be running by default.

@grenzor If you are using computer straight for > 2 hours, it's plausible to go to bathroom/check who's been ringing to you door/et cetera, and forget completely about something like KeePass and its important database. And because of that I propose option stated above.

[droidmonkey]

@912d that option already exists, as we discussed here. The problem that @grenzor has is it is capped at 2.5 hrs. I would consider making the timeout go up to 12 hours, but my standing is there will be a stern warning to a user if they set it higher than 30 minutes since that defeats its intended purpose.

[grenzor]

I would consider making the timeout go up to 12 hours

That sounds like a reasonable upper limit to me.

[seatedscribe]

This is a perfect use case to push for having QuickUnlock implemented ;) Just search for it in the issues for an explanation. I agree with Jonathan White that this is too much of a concern and would avoid warning signals around the program in the first place. When you need to bend something outside of its intended use to obtain what you need, it's plausible you are using the wrong tool...

[phoerious]

I think together with a quickunlock feature, it's a reasonable request.

[TheZ3ro]

I think capping it to 12 hours is ok. (IMHO 2.5 hours is enough most of the time)

There is no need to keep your db opened 3 days if you have quickunlock

[reagle]

I'd like a longer time too.

[ThePythonicCow]

I use this timeout for a different purpose, and would ideally choose it to be about a week.

I live alone ... if any bad guys wander by, they're just going to pick up my computer (wall powered desktop PC) and walk out with it, which will power it down ending all my sessions very abruptly.

I use the timeout so that I won't forget my keepassxc master password. My computer is often up for a half year or a year at a time, going down only to upgrade hardware or install a new (Gentoo Linux) kernel.

If I am not forced to periodically re-enter my KeepassXC password during those months, I forget exactly what it is.

If I have to re-enter it once a week, then I remember it just fine.

However ... I might be too much of a corner case to worry about.

I run off my own builds of keepassxc ... If it was super easy to drop a hint here which number I should change to get my desired week maximum on this setting, then I'm willing to change the source and rebuild my own mutant copy. I looked just now in the newly released 2.3.4 source that I just downloaded (tar ball, not git, if that matters), and I expected to see the value of lockDatabaseIdleSpinBox increased from 9999 to 43200, inline with the 2.3.4 release item: "Allow for 12 hour timeout to lock idle database", however it is still 9999 in the file ./src/gui/SettingsWidgetSecurity.ui, so apparently I don't understand what's going on well enough to change it on my local copy yet.

Thanks!

P.S. -- I suspect that the tarball I downloaded is a few days old, as I see that the 9999 was changed to 43200 here in git three days ago. I'll try the git download, so that I pickup any other recent changes, and then I'll try bumping that 43200 up to a week.

P.P.S -- Mission accomplished. I downloaded the current git developers version, saw that this timeout max was 43200, and changed that to 604800 (a week of seconds) in the file ./src/gui/SettingsWidgetSecurity.ui. That's now rebuilt and working for me.

[droidmonkey]

[ArchangeGabriel]

Seems there is some confusion between the master and the develop branch… I don’t know what devs intended here, but I don’t think it’s right for master to have 28 commits not found in develop, and for the 2.3.4 tag to be on master while most of the advertised changes are on develop.

The tag was made on the master branch, while the mentioned change is in the develop branch only. So @ThePythonicCow that’s why you did not get it when grabbing the 2.3.4 tag.

[jtl999]

@ThePythonicCow

if any bad guys wander by, they're just going to pick up my computer (wall powered desktop PC) and walk out with it,

This exists which can unplug a running desktop PC and plug it into a UPS for forensic and other purposes. That being said I doubt your bad guys are that smart and AC line voltage is owie. ;)

[droidmonkey]

@ArchangeGabriel I haven't merged master into develop yet. There are a ton of conflicts to resolve, it will take time. I am running into a ton of issues trying to build 2.3.4 on Windows thanks to sloppy package management by MSYS2...

[TheZ3ro]

@ArchangeGabriel I agree this is a mess and should be done differently but here we are.
The master branch is pointing to 2.3.4 release and has the 2.3.4 tag.
The develop branch is pointing to the next 2.4 release and has extra commit/feature not present in 2.3.4/master branch

[droidmonkey]

Sorry, I made a mistake, the timeout bump was actually never merged into the 2.3.4 branch so this will make it's debut in 2.4

[ThePythonicCow]

@ArchangeGabriel @droidmonkey @TheZ3ro The devel vs master confusions are no biggie from my personal perspective ... just one more of a bazillion details to figure out ... such is the life of a nerd.

Thanks greatly for all the work that goes into this essential tool.

And thanks for accidentally merging the timeout bump prematurely ... it showed me that what I planned to do on my personal mutant copy, in order to bump the timeout to a week, would have a good chance of working as I desired.

[unknow883]

Agreed with OP. Would like to see at least 24 hours. I am at my computer most of the time but in case I leave the house for a few days and forget to lock.... I already lock my computer. Quick lock/unlock would be helpful only if db was already masterunlocked.