linux-ext4 - [Bug 23732] ext4 timestamp range contains 68-year gaps

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 21 Feb 2015 01:15:57 +0000
From:	bugzilla-daemon@...zilla.kernel.org
To:	linux-ext4@...r.kernel.org
Subject: [Bug 23732] ext4 timestamp range contains 68-year gaps

https://bugzilla.kernel.org/show_bug.cgi?id=23732

Theodore Tso <tytso@....edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |tytso@....edu
         Resolution|CODE_FIX                    |---

--- Comment #10 from Theodore Tso <tytso@....edu> ---
I'm not sure why the test cases have been passing but the true fix hasn't been
applied yet.  This is due to my not having time and the need for us to have
better test cases in e2fsprogs (for both the old and new encodings, etc.)   As
usual, the highly urgent problems with short-term deadlines tend to get higher
priority from the important long-term items.

Specifically, I want to be able to convert time strings to integers using both
the old the new encodings, and then have test cases to make sure that e2fsck
and the kernel are doing the right thing and coverting as necessary as we had
determined in the migration plan for this bug.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html