linux-ext4 - Re: e2fsprogs: building ext2simg

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20171009125902.66u7hsgxsueedquq@thunk.org>
Date:   Mon, 9 Oct 2017 08:59:02 -0400
From:   Theodore Ts'o <tytso@....edu>
To:     Nicolas Dechesne <nicolas.dechesne@...aro.org>
Cc:     linux-ext4@...r.kernel.org
Subject: Re: e2fsprogs: building ext2simg

On Mon, Oct 09, 2017 at 10:24:46AM +0200, Nicolas Dechesne wrote:
> 
> The problems appears as soon as I upgrade from e2fsprogs 1.42.12-2+b1
> (the version in Jessie) to either the version in Stretch or the
> version in jessie-backport. So it looks like e2fsprogrs 1.43, breaks
> something with existing ext2simg (I am using ext2simg from
> android-tools-fsutils, so the 'old' one).

So *that* shouldn't have happened.  I do try to keep the ABI/API of
the libext2fs shared library stable, even across major version
numbers.  That being said, I suspect ext2simg was doing something that
made it highly dependent on the internal implementation detalis of
libext2fs.  It would be interesting to know what in the world that
was, so I can try to avoid that in the future.  But I've always viewed
many of these tools to be quite highly fragile, so I'm not sure
there's much we can do to fix this in terms of changing what libext2fs
is doing.  But if I can fix/improve the backwards compatibility
problem from libext2fs's side, I'm certainly willing to entertain that
notion.

						- Ted