Describe the bug The keyboard on the autofill does not come up when you use KeyPassium autofill for the second time.

To Reproduce Steps to reproduce the behaviour:

1. Set an autofill database.
2. Go to a password input screen app or browser.
3. Select the Password autofill option above the keyboard.
4. the autofill KeePassium option comes up and the keyboard as well for searching.
5. select the option
6. The username and password are filled in.
7. Use another app/website to login.
8. Select the Password autofill option above the keyboard.
9. this time the autofill KeePassium screen comes up but not the keyboard. The keyboard does not even appear after clicking the search icon or focusing on the search box.

Expected behaviour The keyboard should appear when the autofill screen appears. And also after the search icon is pressed or the search box is focused.

Screenshots If applicable, add screenshots to help explain your problem.

User Information (please complete the following information):

• Device: iPhone Xr
• OS: IOS 14.0.1
• App Version: v.19.76

Additional context Add any other context about the problem here.

For some iOS 14 users, files linked to KeePassium remain available only for a few hours. After that, any attempt to access a linked file results either in a timeout, permission denied, or "file doesn't exist" error.

To Reproduce Steps to reproduce the behavior:

1. In KeePassium, add an existing database stored anywhere outside of On My iPhone / KeePassium.

2. Unlock the database to ensure it works properly

3. Use the device normally for some time (reportedly, hours)

4. Open KeePassium and observe one of the following errors:

   • Dropbox does not respond
   • The file couldn’t be opened because you don’t have permission to view it.
   • The file doesn’t exist.

Expected behavior The database should open normally.

User Information (please complete the following information):

• Device: iPhone, iPad
• OS: iOS 14.0, 14.0.1
• App Version: 1.16.73, 17.74

Additional context

This is an extension of the common iOS 14 issue: the new system breaks KeePassium's old references to external files. That issue can be easily resolved by re-adding the files to the app. But sometimes it reoccurs.

This is reported to affect Dropbox, OneDrive, iCloud Drive, DS file, and even local storage. The typical error log is very brief:

Error Domain=NSCocoaErrorDomain 
Code=257 
"The file couldn’t be opened because you don’t have permission to view it."

In one case, there was a more detailed log about OneDrive. The first two messages have been translated from Dutch, the last one was is English.

Error Domain=NSCocoaErrorDomain 
Code=4101 
"Couldn’t communicate with a helper application." 
UserInfo={
  NSUnderlyingError=0x2823b18c0 {
    Error Domain=NSFileProviderInternalErrorDomain 
    Code=7 
    "Cannot connect to extension 'com.microsoft.skydrive.onedrivefileprovider'." 
    UserInfo={
      NSLocalizedDescription=Cannot connect to extension 'com.microsoft.skydrive.onedrivefileprovider'., 
      NSUnderlyingError=0x2823b1920 {
        Error Domain=PlugInKit 
        Code=4 
        "cannot obtain executable path for plug-in com.microsoft.skydrive.onedrivefileprovider(40DB0250-7640-4E5C-9A9E-29DF5B006317)" 
        UserInfo={
          NSLocalizedDescription=cannot obtain executable path for plug-in com.microsoft.skydrive.onedrivefileprovider(40DB0250-7640-4E5C-9A9E-29DF5B006317)
        }
      }
    }
  }
}

Apparently, the system cannot find the OneDrive file provider extension.

Overall, this looks like an iOS 14 bug. But I will collect any relevant info here, as the issue affects more and more people.

I’m unsure if this is a case of KeePassium doing the AutoFill methods in a different way than the iCloud Keychain, or if it simply is that Apple is not using their own API for their AutoFill. As I’m using the iCloud Keychain as the ground truth here, it may all be null and void based on the assumption that it should behave the same.

In Safari it seems the behavior is as expected, but when entering credentials inside Apps there is some odd behavior in the UI.

In a gist; When using AutoFill and selecting the entry I’m returned to the App, with the focus on one of the fields, and sometimes also outside the fields, with a blinking caret indicating the field is active. If I tap on any of the fields related to the login they stay blank, and also if I push outside, the fields now losing focus. As soon as I tap one of the user or pass fields again, after their focus has been lost, the credentials simply pop in.

In the cases where the fields are not filled this pattern can be repeated over and over without the credentials showing in the fields, invoking AutoFill multiple times. As soon as you tap outside and then in one of the fields again they “automagically” appear.

With iCloud Keychain I’ve tried this about 20 times, never seeing the same behavior. When using KeePassium it is roughly 50/50 on a run of 20 tests, with the longest streak without being able to reproduce the issue being 5 times.

Not done a proper profile how this differs between apps, but I’ve had the same behavior in multiple apps. From my memory I recall a handful of them, sadly local apps only on the Swedish App Store. Will hunt for a international one that can be used to reproduce.

I’ve captured the behavior in one App using iOS screen capture. Can’t manage to attach them through my iPhone, but I’m linking the clips on dropbox. Good to know: Användarnamn = User name Lösenord = Password

As the iOS Screen Capture does not indicate where taps happen the best way is to look where the caret (text entry marker) is placed, as that is the clearest indication of what field is in focus.

Also, the whole on-screen keyboard goes away whenever the user or pass field is not in focus.

The following link should go to a Dropbox folder where you can find 5 clips: https://www.dropbox.com/sh/gr0840td25sdl0x/AAA3ZvWvcUPRWgiFRDGidqGpa?dl=0

Clips 1-3 are different variations on altering field in focus before taping outside of formed and then back in the login form.

Clip 4 is a case where returning to the app none of the fields are focused.

Clip 5 is when doing multiple AutoFills after each other without the fields getting filled until “onblur” and then focusing on the username again.

Describe the bug I’m not sure where you’re at in the process of supporting dark mode, but I wanted to let you know that the application doesn’t look good in dark mode. I opened the application this evening and dark mode was automatically enabled within KeePassium because my system settings are set to switch between light mode and dark mode depending on time of day. I noticed that most of the text was impossible to read and there were a lot of inconsistencies between screens and parts of the screen. By the looks of it you haven’t gotten to far in the process, but I thought I’d open an issue anyways and attach some screenshots to show you what I’m saying.

To Reproduce Steps to reproduce the behavior:

1. Enable dark mode
2. Open KeePassium

Expected behavior I expected it to look readable and consistent. I think if dark mode support isn’t ready within the application then it should default to light mode until it is.

Screenshots Attached

User Information (please complete the following information):

• Device: XS Max
• OS: iOS 13.1 beta 3
• App Version: 1.02.34.

Describe the bug Clicking "Create New Database" exits the app immediately.

To Reproduce Steps to reproduce the behavior:

1. Open the app
2. Click on "Create New Database"
3. Observe the app crashing

Expected behavior Being able to create a new database.

User Information:

• Device: iPhone SE (2016)
• OS: iOS 14.0.1
• App Version: 1.17

Additional context I'm not sure if this is related, but clicking "Enable AppLock" under "Protect KeePassium from unauthorized access" also crashes the app.

Deleting the app along with its data (via Settings > General > iPhone Storage) has no effect.

First of all, I want to thank the developer for the excellent app. KeePassium makes it easy to switch from 1Password and the price is reasonable.

Description I am using pCloud to sync my KeePass database, but I get the error in KeePassium: "pCloud does not respond " or "database is unreachable".

The pCloud app has a folder MyData which contains the KeePass databae. This folder is set to "Make Available Offline".

There is no problem with Internet connectivity.

How to reproduce Steps to reproduce the behavior:

• Restart iPhone & launch KeePassium
• Enter Passcode
• KeePassium tries to load the db, but fails with "database is unreachable..."
• In the Databases screen it shows: "pCloud does not respond"
• reproduced multiple times

Expected behavior

• no such errors
• database should be available immediately after restart

Environment:

• Device: iPhone XS Max
• OS: iOS 15.6
• App Version: v1.35.114

Screenshots

Keepassium When adding a database through the system's "file", the source is a third-party cloud, I found that the Keepassium does not automatically synchronize, sometimes it will not automatically synchronize for a few days, when you manually pull down the refresh, it will not automatically synchronize ，Only when you perform an open database through the top right corner, through the system's "file", the fact is that you do not need to add it again, just need to open this step, and then exit, the database will synchronize the latest data。

Describe the bug When updating the database locally (in "On my iPhone"), the app asks for the password/keyfile again even though the file name is the same. I didn't have the problem before you changed something in 1.15/1.16, the app remembered the master password for this database.

To Reproduce Steps to reproduce the behavior:

1. Update the database file in "On my iPhone"
2. Launch Keepassium (it will say the database file doesn't exist)
3. Select the "new one"
4. Reselect keyfile and write password

Expected behavior The password/keyfile should be remembered when updating the file especially when it has the same name and is in the same location.

User Information (please complete the following information):

• Device: iPhone 11 Pro
• OS: iOS 13.7 and iOS 14
• App Version: 1.16 and 1.17 (and perhaps 1.15)

Describe the bug

If the iCloud Drive service for the user's AppleID is disabled, then when the KeePassium AutoFill is opened and the user taps to add a database the app displays "Something went wrong while displaying documents". This error does not happen in the main app. It does not matter what the last Files Picker location was, or what other Files services are enabled.

To Reproduce

Steps to reproduce the behavior:

1. In "Settings > AppleID > iCloud" disable "iCloud Drive"
2. Open any app or website that will present password autofill
3. Use a password field to invoke KeePassium AutoFill
4. Navigate to the Databases screen
5. Tap "+" to add a database
6. Observe the "Something went wrong..." error
7. In "Settings > AppleID > iCloud" re-enable "iCloud Drive"
8. Repeat steps 2-5
9. Observe that the error is gone, and the Files Picker appears

Expected behavior

The Files Picker appears after tapping "+" on the Databases screen instead of the "Something went wrong..." error message.

User Information (please complete the following information):

• Device: iPhone 8
• OS: 13.4.1
• App Version: 1.11 beta

Description The Keepassium app briefly shows the splash screen with its logo before crashing back to the home screen.

How to reproduce Steps to reproduce the behavior:

1. Download the Keepassium app from the App Store
2. Tap on the Keepassium app at the home screen
3. Watch the splash screen momentarily appear before the app crashes back to the home screen.

Expected behavior The app will launch normally as it would have on other iOS-based platforms (e.g. iPhone) without crashing.

Environment:

• Device: iPod Touch (latest model as of Dec. 2021)
• OS: iOS15.2
• App Version: 1.30 (as listed in App Store)

Additional context

• This issue does not seem to occur on iPhone models with the same iOS & app versions.
• Removing and then reinstalling the app has already been attempted and did not result in success
• Is it possible that something related to the lack of biometric authentication for iPod Touch devices may have caused the error (just a hunch)?

Describe the bug When I change the database on my iPhone (add some entry etc.), I can no longer access it when I reopen the database (says the password or keyfile is invalid). I transfer the file to my computer (using iCloud drive, Google drive etc.) and I can't open there as well (HMAC mismatch).

To Reproduce Steps to reproduce the behavior:

1. Open a database (local, Google Drive or iCloud drive, don't matter)
2. Add new entry and save
3. Go back to databases list
4. Reopen the database
5. See the error (Invalid password or key file)
6. Retype the password, still error
7. Transfer the file to a computer
8. Try to open with KeepassXC, get HMAC mismatch

Expected behavior I should be able to reopen the database with my password.

Screenshots I can add if necessary, but I don't think it'll help.

User Information (please complete the following information):

• Device: iPhone 11
• OS: iOS 14.0.1
• App Version: 1.18

Additional context I can add if necessary but I can't think of anything else right now.

Description When you open a database, the first option of the database is selected(the first group's first entry)

There's no way to back out, if you try to exit selecting said entry, via slide out or the back button, the app will reselect the first entry

There's no way to select another entry because of that

How to reproduce Steps to reproduce the behavior:

1. Open the app
2. Select a database
3. Observe the behavior when trying to back out of selecting said entry

Expected behavior The app should let you exit selecting said entry

Environment:

• Device: iPhone 7 Plus
• OS: iOS 14.3
• App Version: 1.39.122 beta

Additional context Sorry I don't really know how to reproduce it just "happened"

When you have long and complex password that you want to share with you're friends or family, it's a annoying, Instead we could generate a QR code and share that qr code with people instead.

Description Once I sign into OneDrive using KeePassium, I can see the shared folder (it was shared with me and it contains a password database) but the folder appears empty.

How to reproduce Steps to reproduce the behavior:

1. Create a folder on consumer OneDrive with a KeePass database using one Microsoft account (let's call this User1)
2. Share the folder with a different Microsoft account (let's call that User2) (with edit rights)
3. Observe that when signed in with User2 on the iPhone OneDrive app, you can see the shared folder and see the .kdbx file in there
4. Try to use the new KeePassium functionality to sign into OneDrive on User2's iPhone. Accept the 2FA prompt, accept access to OneDrive for KeePassium app.

Expected behavior After all of the sign-in things have been done, UserB can see all of the accessible OneDrive folders including the folder shared by UserA. But the folder appears EMPTY. There is nothing in it. I have verified that both in UserB's OneDrive app as well as web browser, the shared folder contains the .kdbx file.

Environment:

• Device: iPhone 12 Pro Max
• OS: iOS16.2
• App v1.40.123

Additional context KeePassium works with the database in a shared OneDrive folder perfectly happily if going through the iOS OneDrive app, it is just the new functionality that seems to present the folder but does not "see" the password file in it.

What can be improved? I'm able to add a self-signed certificate to iOS settings, so that Safari accepts it, but the same certificate won't be accepted by KeePassium.

The solution you'd like Any of this would work:

• Accept self-signed certificates (or add a toggle for that) that are trusted by the OS.
• Show the invalid certificate and allow white-listing this specific certificate.
• Allow selecting a pem file that matches the one used by the WebDAV server.

Additional context I configured a WebDAV server on a PC on my local network, and would like to configure my other devices to sync with this WebDAV server, so I don't have to rely on any cloud storage. This works fine, but I would need to have a valid certificate. Trusting any certificate would be the same as dropping the SSL (some man in the middle could use a different certificate and act as a proxy), and I would like to be able to sync my DB on networks other than my own.

Currently, sensitive data in the keychain is protected by three factors:

• App logic — once KeePassium is unlocked, it can read/write/delete keychain items without additional restrictions.
• kSecAttrAccessibleWhenUnlockedThisDeviceOnly attribute
• Additional encryption by a device-bound key stored in the Secure Enclave

It would be useful to compliment the app logic with keychain-based verification, where the system itself would verify user-defined access conditions.

For example, the user could configure the app to require a biometric scan (or PIN code) to open the database. Instead of doing the check in the code, the app should set the corresponding attribute on the keychain item. This way, access control would be enforced by the system rather than the app.

This would be a prerequisite for #42 and #169.

[thanks, Konstantin and Andy]

Description When I'm in dark mode and App Protection is enabled, the UI goes black instead of the default grey.

UI when App Protection is enabled (before entering credentials):

UI with App Protection is disabled or on login (default dark mode behaviour):

How to reproduce Steps to reproduce the behavior:

1. Install keepassium on macos
2. enable App Protection
3. close and open keepassium

Environment: macOS Ventura 13.0.1 Keepassium 1.38.119