Activity for Mitch Ames
-
Mitch Ames posted a comment on ticket #1598
Fixed the access to BR1547, you should be able to read it now. Thanks, I can read it now, but I don't understand. Is "working as designed" here because you disabled the rollover (switching to date_time) to fix bug 1547? I just tested with v3.56 and the rollover from 999 to 001 works as I expected (with 5 backup files), then stops working (ie switches to date_time) when I repeat the test with v3.57. Perhaps - per bug 1547 - there was/is a problem when Max backups is 999 (an obvious edge-case), but...
-
See https://sourceforge.net/p/passwordsafe/bugs/1547/ I don't have access to that page - it says "Forbidden. Sorry, the permissions for this page don't allow you to access it."
-
v3.66 crashes if pwsafe.cfg is missing
-
Intermediate backup, incremental number does not rollover from 999 to 000/001
-
Add Entry dialog - both Group and Title have green background
-
OK. Thanks for that.
-
Some observations and requests/suggestions after testing pwsafe64-3.65.0-bin on Windows 7 SP1 (64-bit) and Windows 10 (64-bit) ... Screen capture protection does not work on Windows 7 (Password Safe is still supported on Windows 7, according to https://pwsafe.org/) - it displays a red "Er" in the graphic. If it is not technically feasible for it to work, please consider: * adding something to the help file to say so and when running on Windows 7: * hiding/removing the graphic indicator from the login...
-
It looks like the same problem occurs with "other value last changed on". Reproduced by changing only the URL field in an entry in file1 then sync from file1 to file2.
-
File->Synchronize does not sync "password last changed on" timestamp
-
Fix verified. Thanks
-
... set a registry key ... Which registry key? What are the values? (I don't run the installer at all - I just unzip pwsafe64-*-bin.zip)
-
Do you recall if you use any other apps before the screen lock occurs No. There are no other apps running (I closed them all before the test). I just ran PasswdSafe, opened the file and then waited. There may be other background tasks running, eg "Fitimo" syncs to smartwatch (measuring fitness things). have you changed any settings regarding how apps are canceled (via say developer options) Nothing that I'm aware of. Certainly no developer options. Or, are there any power saving settings enabled...
-
Remove "screen capture protection is on/off" icon from windows
-
Auto-close on removal of external storage containing data file
-
"File close timeout" not working
-
Exclude Password Safe from screen capture in Windows 7
-
Inconsistent terminology - Safe Combination, Master Password
-
OK thanks Also updated the help file Remember to search the entire help file for references to pwsafe.cfg and updated them if necessary - I just noticed one in the Filter section: "... autoload_filters.xml in the same directory as the pwsafe.cfg file (by default the directory where Password Safe is installed)"
-
Also in pwsafe-3.57.0-src\src\core\PWSprefs.cpp I see } else { // User specified config file via SetConfigFile() // As per pre-use of Local AppData directory, // If file name's relative, it's expected to be in the // os-specific config directory stringT sDrive, sDir, sFile, sExt; pws_os::splitpath(m_configfilename, sDrive, sDir, sFile, sExt); if ((pws_os::IsWindows() && sDrive.empty()) || sDir.empty()) m_configfilename = sCnfgDir + sFile + sExt; } However that does not look right. Should it be sDrive.empty...
-
It's possible that the Help file needs updating regarding Password Safe Preferences, in particular the location of pwsafe.cfg. Is the statement "By default, pwsafe.cfg is kept in the same directory as the pwsafe.exe executable program" necessarily true now? I suspect that (even if the directory is writeable) the software will read the file from the exe directory only if it already exists, but if it does not already exist it is created in %localappdata%\PasswordSafe by default.
-
I just downloaded the source code for v3.56 and 3.57 and compared them. PWSprefs::FindConfigFile() has changed, in particular from: if (sDrive.empty() || sDir.empty()) m_configfilename = sExecDir + sFile + sExt; to if ((pws_os::IsWindows() && sDrive.empty()) || sDir.empty()) m_configfilename = sCnfgDir + sFile + sExt; This is probably (part of?) the problem. Note that IsWindows && sDrive.empty might be assuming that Windows paths always have drive letters - but UNC paths do not have drive letter...
-
I tried specifying a UNC path for a file to encrypt, and that works OK: \\VBOXSVR\Temp\password-safe-portable-357\pwsafe -e \\VBOXSVR\Temp\password-safe-portable-357\file.dat However it looks like the UNC path to config file does not work correctly in earlier versions for all scenarios. Eg 3.55 set PWS_PREFSDIR= C:\temp\password-safe-portable-355\pwsafe C:\temp\password-safe-portable-355\pwsafe.psafe3 -u mitch -h portable -g \\VBOXSVR\Temp\config-only\pwsafe.cfg creates and uses C:\temp\password-safe-portable-355\pwsafe.cfg...
-
I couldn't reproduce this problem using the Visual Studio debugger. Can you (or anyone else) reproduce the problem with the standalone release build? The relevant code hasn't changed since 2017, ... v3.56 includes bug fix SF1542 "UNC paths now accepted as backup directory", which might possibly be related. That being said, I just tested 3.56 and it appears to work OK. My problem only appears in 3.57. perhaps the problem is in the Windows environment? I can reproduce the problem, in a variety of different...
-
Password Safe v3.57 does not load config file from UNC path
-
prompt that "entry has been changed" when it has not, after changing then viewing password policy
-
encrypt large file with -e
-
The new version (...g7e41430b6+) seems to be working OK. I did notice that if I create a new database with the new version, with a single entry with multiple paragraphs in the Notes (pwsafe2.psafe3, same combination) as before, then open that database with v3.53 (or 3.52), then 3.53 has the same issue - telling me the entry has changed if I display it, when I haven't changed anything. I get the same thing if I add an entry to my real database with 3.54.1, then open it with 3.53. (Possibly this is...
-
I just checked on Windows 10, 64-bit, and get the same behaviour.
-
I can reproduce the problem with a single test entry. On Windows 7 SP1 64-bit, with 64bit versions of Password Safe, and default configuration: Run v3.53 Create new database In options, enable "Show Notes in Edit" (may not be required) Add the single entry, with multi-line Notes. The Notes text was typed into the pwsafe dialog, not copy-pasted. (file is autosaved by default) File, Exit Run v3.54.01 (heads/master-0-g86388a52f+) Open the database Right-click the entry, and Edit Entry (without changing...
-
On Windows 7 64-bit, v3.54.01 (heads/master-0-g86388a52f+) 64-bit works, including Help About, but... If I View/Edit some entries with Notes, then click Cancel without making any changes, it says "This entry has changed. Are you sure you wish to cancel?" Entries without Notes don't have this problem. Not all entries with Notes have the problem - I haven't checked exhaustively, but it looks like the problem exists with entries whose Notes include multiple paragraphs and/or a trailing CR/LF. (Possibly...
-
I also confirm that the GetDpiForWindow problem is fixed with Windows 7 SP1 64-bit and pwsafe64. (It also works on Windows 10 64-bit) Also that Help/About does nothing. Thanks for the quick work.
-
I can confirm the same error with Windows 7 SP1 64-bit and 64-bit pwsafe (downloaded from link at https://sourceforge.net/p/passwordsafe/bugs/1526/#a3a1) (... and also add request for ongoing support for Windows 7, and my willingness to test betas on that OS if necessary.)
-
Issues with Easy-to-read and Pronounceable password lengths
-
Fix verified with V3.52pre (ga7b117a38+) 64-bit built Apr 12 2020 19:54:05 Thanks
-
Fix verified in V3.52pre (gc7a927f55+) 64-bit built Apr 11 2020 12:11:04 However note that this version seems to have introduced a new bug: https://sourceforge.net/p/passwordsafe/bugs/1513/
-
"Parameter is incorrect" on default password policy
-
Pre-release V3.5.2pre (gdc336b216+) 64-bit built on Apr 10 2020 11:22:14 - from https://sourceforge.net/p/passwordsafe/bugs/1512/#485d - fixes the problems I described above ( https://sourceforge.net/p/passwordsafe/bugs/1497/#2453 )
-
Enabling Default Username does not allow blank username for any (existing) entry
-
See also https://sourceforge.net/p/passwordsafe/bugs/1497/
-
In a Windows environment it might be feasible to enable Windows' own audit logging of the .psafe3 file access, e.g. as described at https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/apply-a-basic-audit-policy-on-a-file-or-folder I just enabled that auditing on Windows 7 Ultimate, and Windows does log the access to the file(s). Note that configuring the auditing correctly is not a trivial exercise - it requires some technical knowledge of Windows, but it can be done without...
-
There's something odd going on here. v3.51 (g18fb9761e+ 64-bit Built on Dec 26 2019 19:58:34) seems to have introduced that bug (for me) rather than fixing it! I'm using 64-bit Password Safe on 64-bit Windows 7 SP1 I have several database entries with recurring expiry dates, typically 365 days, and I usually generate new passwords before the expiry date, and all versions up to and including 3.50 have worked as expected, resetting the expiry date (to 365 days in the future) when I generated a password....
-
Password Expiry in n days should be Recurring by default
-
Fix confirmed in v3.51 Thanks
-
I confirm that this is fixed in v3.50 Thanks
-
Clicking "Password" on Edit dialog of alias entry does not copy alias base password
-
The visibility/checking of the "at least" fields on database entries (with "Use the Policy below" instead of default or named policy) is still a related problem. E.g, with 3.50.0pre2 Create a new database. Create a database entry with a password policy of length=12, at least 8 lowercase, no uppercase, at least 1 digit, no symbols, Easy-to-read. Save the entry. Edit that entry's policy again. Change length to 8. Messagebox says "length is less than sum of 'at least' constraints" - but I can't see...
-
(With 3.50.0pre2 ...) If I repeat the same process but use Pronounceable instead of Easy-to-read, the policy ends up showing all of the symbols (both in the Change/View dialog and Manage Password Policies dialog) but only appears to use the easy-to-read symbols.
-
With 3.50.0pre2 (3, 50, 0, heads/BR1494a-0-gfaaecc6bc+), and the scenarios in https://sourceforge.net/p/passwordsafe/bugs/1494/#7ec3 ... Scenario 1 appears to be fixed now. Scenario 2 is unchanged. Password Safe tells me that it is ignoring the "at least" values, but does not ignore them when validating the entry ("Password length is less than sum of 'at least' constraints"). Scenario 3, policy4 now shows "at least n" symbols in the Manage Password Policies dialog. Scenario 3, policy5 is still a...
-
I haven't touched the enable/disable logic, ... This leads to apparent failure to save changes, eg (with 3.50.0pre2): Create a new password policy, with at least 2 lowercase and at least 0 upper, digits symbols. Edit that policy to untick Use Lowercase (leaving "at least 2") and save. Edit the policy again. Change "at least 2" (lowercase, which is not ticked) to "at least 3" and save. Edit the policy again. The "at least" control has gone back to 2. Not a problem here, because it's not being used....
-
The problem also exists in 3.50.0pre2 (3, 50, 0, heads/BR1494a-0-gfaaecc6bc+), from https://sourceforge.net/p/passwordsafe/bugs/1494/
-
An easy-to-read password policy may generate passwords with hard-to-read symbols
-
Is the "at least n" upper/lower etc intended to be supported now with Easy-to-read? Recent changes to 3.50.0pre1 and pre2 suggest that it is, but there are still inconsistencies with the visibility of the "at least" fields. Examples, with 3.50.0pre2 (3, 50, 0, heads/BR1494a-0-gfaaecc6bc+): Create a new database Edit the default password generation policy thus: Set "at least 2" lowercase, uppercase, digits, symbols. Tick Easy-to-read. The "at least" fields remain visible in the Change/View dialog,...
-
... display a message box telling the user that it has detected an inconsistency and has deleted ... Actually it should display a messagebox if it detects an inconsistency even if it does not make any change to the data. Any sort of inconsistency implies the risk of data loss, either previously (creating the inconsistency) or in the future. The sooner the user knows about the problem, the sooner the data can be recovered, and the more likely a useful bug report can be submitted.
-
I haven't dealt with smarter error recovery and reporting, nor with comparing password policies as part of databqase compares - these should be separate tickets. https://sourceforge.net/p/passwordsafe/feature-requests/879/ - warn user if inconsistency detected https://sourceforge.net/p/passwordsafe/feature-requests/880/ - compare password policies
-
Compare Database function to also compare password policies
-
Warn user if a password generation policy is deleted because it is inconsistent
-
In "nested view" change group icon colour to indicate expired password therein
-
Pressing Enter after typing policy name when creating new password policy incorrectly reports "Policy Name is blank"
-
There are still a few problems with 3.50.0pre1 (version "3, 50, 0, heads/BR1494-0-g712576511+"). Scenario 1: Create a new database with 3 database entries and 3 password policies (1 used by each database entry) per original report. Edit password policy1 thus: Untick "Use lowercase letters". The "at least" control is disabled, but still shows 12. Note that the "at least" controls for the other unticked options are not disabled, so there is an inconsistency here (see Scenario 4). Change password length...
-
More information (which might be more suited to #1492) ... When I edited the named policy1 to make the password length shorter than minimum lower case letters, with easy-to-read enabled, Password Safe allowed it without warning, and then later the policy was lost. However if I edit a database entry's policy directly, thus ... Create new database entry, with entry-specific policy ("Use the Policy below") of length=16, at least 12 lowercase, no uppercase, at least 1 digit, no symbols, only easy-to-read,...
-
See also https://sourceforge.net/p/passwordsafe/bugs/1494/
-
Password policies are lost if both "use only easy-to-read characters" and "at least n" are enabled
-
... we currently don't support ... Fair enough but consider: The "at least..." controls do not disappear immediately when I tick the "use only easy-to-read..." checkbox, so it's not obvious at the time that I set the policy that those controls are not supported. Compare this with the behaviour when I tick "use hexadecimal" - the "at least" fields are greyed out immediately. (Consistent use of greyed-out vs invisible would be helpful.) In at least some cases the "at least" is apparently being used....
-
Password Policy tab not updated when changing policy
-
In case it wasn't clear, when I "change Password Policy to select easy-to-read", I selected "Use the policy below" - ie I edited the rules for that entry only, I did not change the stored policies (used for multiple entries) under Manage Password Policies
-
Password policy - "Use at least n" not visible with easy-to-read characters
-
I can also confirm that 3..47.2 fixes the problem. Thanks
-
I have: Edition: Windows 10 Pro Version: 1803 OS build: 17134.254 Most recent update was "2018-08 Cummulative Update ... KB4346783", installed 2018-08-31
-
I can reproduce the problem with Windows 10 Pro, 64-bit, Build 17134 and Firefox Portable 61.0.2 64-bit. The password can only be pasted only once into https://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox&action=edit. If I use Internet Explorer 11 (64-bit) in Windows 10 I cannot paste the password at all! (I can copy/paste other text - not copied from Password Safe - so I know the clipboard works in general with IE11.) However I can paste the password multiple times into Notepad or Edge.
-
pwsafe 3.47.01 can't paste password twice into a browser
-
Changing unlock difficulty does not enable File Save, hence does not get saved
-
Feature request: Please change the colour of the group icon in tree view, so that it is red (or half red) if one or more of the entries in the group or subgroup has an expired (or soon to expire) password. I use tree view, generally with all groups collapsed, and I can't see the red icon of an entry with expired password until I expand the group - which I might not do each time I run the program. It would be handy if the group icon colour reflected the status of any expired (or nearly expired) entry...
-
So either 3.38.2 or 3.40 will be the last PasswordSafe version to run Windows XP....
-
What's the story with support for XP? I've been using Password Safe on XP (and Windows...
-
What's the story with support for XP? I've been using Password Safe on XP (and Windows...
-
What's the story with support for XP? I've been using Password Safe on XP (and Windows...
-
What's the story with support for XP? I've been using Password Safe on XP (and Windows...
-
I can't reproduce this in V3.38 I've just checked each of the specific scenarios...
-
Thanks
-
Fails to import from XML when entry uses default policy
-
Version 3, 36, 1, g8fe4cbc seems to have fixed the problem. Thanks
-
Yes, I'd like to test the fix / pre-release.
-
Can't store filter that uses policyname in database
-
With 3.35.1.exe from https://sourceforge.net/p/passwordsafe/bugs/1231/#e59d ... (All...
-
Password policy: sum of 'at least' constraints" incorrectly includes values from unticked options
-
That prerelease (https://sourceforge.net/p/passwordsafe/bugs/1228/#7750) fixes the...
-
Easy-to-read and pronounceable policy hides "at least n" controls
-
3.35.1 fix confirmed
-
Attached are databases created by v3.34.1 for each of the two scenarios. The password...
-
"Open as read-only" check-box does not always have the correct state
-
This bug still appears in v3.35 - has it been forgotten, or is likely to be fixed?...
-
Can't use "hex digits only" when generating password from Ctrl-P
-
Changing password policy that was set with earlier version causes v3.35 to hang
-
Column Picker messes up columns if something is dragged to left of Icon column
-
Generation rule of "at least zero" not supported
-
"Open as read-only" check-box does not always have the correct state
1