Self contained,
Always using the right version.

Todo:

• Embed KeePassLib
• Perform Version Checks
• Consider and Protect against security risks of embedding the KeePassLib

What do you think of the idea to change the Get-KeePassEntry cmdlet so it does not require group and title? Then I can use standard PS cmdlets for filtering after I have got all entries. This would enable me to search databases for entries without expiries, weak passwords, e.g.

Get-KeePassEntry | Where-Object { $_.Expiry -eq $null }

Am happy to submit PR for this if you think it would be beneficial to the project.

Use a .format.ps1xml file to format output views and tables instead of inline code.

Consider adding Notes to Entry and Group Default views.

• Remove-KPGroup
• Remove-KPEntry

Functions like...

• Get-KeePassDatabase
• Set-KeePassDatabase
• New-KeePassDatabase
• Remove-KeePassDatabase
• Get-KeePassCompositeKey
• Set-KeePassCompositeKey
• New-KeePassCompositeKey
• Remove-KeePassCompositeKey

In order to do this I think we will need to use a parameter set.

Hi I just found your project, I have also been working on a PowerShell KeePass module with the same basic intentions.

I noticed some strengths in your code versus mine and vice-versa. Potentially we could consider working on the same project and bring the best of both worlds together.

Check out my project here and let me know.

Potentially this could be saved in the config, as well as a parameter to Import-KPLibrary.

This will require that the function Import-KPLibrary to be exposed to the user.

Added default display members to return objects.

Get-KPCredential Needs to be updated to handle if only the database file is passed.
New-KeePassDatabaseConfiguration Needs to be updated to handle this as well.

Update Naming Convention to latest standard as per the wiki.

Basic Requirement entails, including KeePass in the Name.

EX:

Get-KeePassEntry

It's more of a suggestion than a question, but how about instead of having a Get-KeePassEntry function having a switch to provide the password as plain text, we should provide the with a consistent PSObject having a secure string for a password, and a function which would convert the secure string as plain text ?

The syntax would be something like

$KeePassEntry.Password | ConvertFrom-KeepassPassword

plain password

If the recycle bin is enabled but has never been used then the group is not created.

The current code will see that there is no recycle bin and permanently delete the entry or group.

As discussed we will integrate these two projects using the PowerKeePass module code as a backend framework for the frontend module code from original PSKeePass project.

Todo's:

• Go through PSKeePass cmdlets and see what backend cmdlets need to be created to support these cmdlets.
• See what backend cmdlets need to be updated or modified to support features of the frontend.
• Update frontend code to use backend
• Update frontend to support extra features that the backend already supports.

Disabled pipeline support for now, until I can figure this out.

Pester Tests will use a sample keepass databases.

• Create Sample Databases for different authentication testing.
• Create Pester tests

Currently there are two functions that perform different steps in getting a KeePass database Connection.

Get-KPConnection
Invoke-KPConnection

As discussed this needs to be merged into one function called New-KPConnection.

This function will handle both steps of the connection process.

As discussed creating a new xml object and using the Load() method is more effective than using the Get-Content command.

Currently Get-KeePassEntry and Get-KeePassGroup return keepasslib objects except when the -asplaintext option is specified.

As Discussed the functions should always return a powershell object, as the user will not know how to interact with a keepass object.

I believe there is some antiquated code that needs updating here:

Get-Help ConvertTo-KPPSObject -examples

Under the second example:

Example #2

    PS>Get-KeePassEntry -KeePassonnection $DB -UserName "AUserName" | ConvertTo-KeePassPsObject

The flags -KeePassonnection and -UserName do not exist (although a -UserName may be nice to implement)

Add Support for Gettting, Setting, and Adding Custom Fields.

Add Windows Logon Authentication.

Requires Powershell 5
This would be an optional method for authentication to a KeePass database.

Allow New and Update functions to specify Icons.

Added Dynamic Parameter MasterKey

Added optional Parameter -MasterKey to core functions.

This parameter was added to allow for easier scripting with databases that use a masterkey password.

Previously if a masterkey password was used the updated functions would prompt the user of the masterkey after the funciton was called. This is still the behaviour if the masterkey is required but not specified.

As discussed ReadSafe is more thread safe than ReadString.

I could add this to wiki for discussion, but currently the code I added from my project has "Strictly Typed" parameters meaning they are typed as something specific to the KeePass SDK.

Ex: ([KeePassLib.PwDatabase])

    [CmdletBinding()]
    param
    (
        [Parameter(Position=0, Mandatory)]
        [ValidateNotNullOrEmpty()]
        [KeePassLib.PwDatabase] $Connection
    )

This means that the SDK must be loaded before the majority of cmdlets will function. I do not think this will be an issue going forward once issue #2 is complete however, in the meantime I solved this issue in my previous project by loading the DLL at the bottom of the module (where you export the various cmdlets in the module).

Alternatively I could remove the strong typing and set all of these parameters to a custom powershell object type, however this will reduce parameter validation and make the code more ambiguous.

Thoughts?

It would be quite useful to display the notes field from an entry. It could be a flag on -plaintext or a setting for the database's profile. But beyond username and password , the notes field is absolutely critical (at least for me).

Also, this module is MUCH appreciated. Thanks!

What is the future of {Get,Set}-KeePassConfiguration? You are embedding the KeePass binary, leaves only the DB and Key File properties.

Will you remove these functions? I'm asking because replace it with something like https://github.com/PoshCode/Configuration. This would also make it possible to have per user settings, even the module is installed in the host module directory.

@chritea, So I started looking into the powershell gallery and I saw no requirements for pester. I was wondering where you saw or heard about this requirement. I still intend to create pester tests, just curious if I am missing something.

Previously options like -UserName were supported to perform filtered lookups.

I like this method as it can be much faster and more secure than just dumping the entire database.

This needs to happen and documentation needs to be updated.

Since the uuid of a group changes per call, it is not a valid look up method.

Since this is the case and a user can return -asplaintext or not from the Get-KeePassGroup function then Pipe it to the Update-KeePassGroup function. There is no great way of determining the actual group to update.

By changing this option to Return the path with the database name I will be able to remove the anonymity of the group that is getting passed.

Unfortunately this is a bigger change as a poor design decision was made early on.

Cmdlets to show different keepass objects.

Example:

Show-KeePassGroups: would show all groups on the top layer and would have a recurse option... etc.

Additional Methods to Generating a Password:

Currently Supported

1. User Selected Character Sets with advanced rules.
2. None... use Default Character Sets with advanced rules.

To Be Supported

• Generate Using Pattern (with options)
• Generate Using Custom Algorithm
• Derive from Previous Password
• Use Built In Profiles, such as:
• 40-Bit hex Key
• 128-Bit Hex Key
• 256-Bit Hex Key
• Random MAC Address
• Allow for Collect additional entropy options
• Smaller Subset Character sets.
• Custom Character Sets
• User Entered Password

Both user facing and base functions/cmdlets that do dangerous operations (set,update,remove,etc) should use the Cmdlet Option of SupportShouldProcess.

When the top level code makes a call to the base code it can then use the -confirm:$false flag to bypass its ShouldProcessing logic.

This way no matter if you are scripting using the base functions or simply using the cli stuff you will always be prompted.

• New-KeePassEntry
• Update-KeePassEntry
• New-KeePassDatabaseConfiguration
• New-KeePassGroup
• Update-KeePassGroup