> On May 23, 2016, 11:20 a.m., David Faure wrote: > > Please note that: > > * the Q_BYTE_ORDER change was reverted, since it made the wallet storage > > incompatible with previous releases. This needs further analysis in order > > to improve the code while retaining compat. > > * kwallet is definitely usable with a home install, I'm doing that right > > now. I do have the distro KF5 packages installed though, so maybe the > > polkit stuff got installed at the right place into the system as well. > > Anyhow it means it should be fixable with a one-time copy operation as root. > > Michael Pyne wrote: > That reminds me, I made an autotest for the Blowfish cipher that would > hopefully catch such errors in the future. I've committed the autotests now > (they pass, hopefully they don't break CI!). > > With that autotest I think that Allen Winter's last Q_BYTE_ORDER change > had actually been correct (to enable the relevant code sections when > Q_BYTE_ORDER == Q_LITTLE_ENDIAN), but his first commit (to #include > qglobal.h) would have generated incorrect Wallets which would then not match > with KWallet when it was fixed. > > Either way someone's systems are being broken here, because the current > code unilaterally enables bit-shuffling always no matter if the CPU is > big-endian or little-endian. But I don't have a big-endian machine to test on > to make sure a fix would (or would not) work. > > Pino Toscano wrote: > This indeed shows that the current situation (kwallet 5.23) is broken on > big endian platforms; looking at the failures we got when it was uploaded to > Debian few days ago, > https://buildd.debian.org/status/logs.php?pkg=kwallet-kf5&ver=5.23.0-1&suite=sid, > we've got failures (related to this) on mips, powerpc, and hppa (s390x is > not built yet, but it will fail there too) -- all of them are big endian. > > I can help in testing patches fixing the `blowfishtest` unit test on > those platforms. > > > the current code unilaterally enables bit-shuffling always no matter if > the CPU is big-endian or little-endian. > > A simple fix could then be use QtGlobal again, but invert the byte order > conditions like: > -#if Q_BYTE_ORDER == Q_BIG_ENDIAN > +#if Q_BYTE_ORDER == Q_LITTLE_ENDIAN > this would preserve the compatibility with little endian platforms, > although breaking wallets on big endian machines. > > Michael Pyne wrote: > If you can test a patch, I'd recommend Allen Winter's last fix attempt > before the whole thing was reverted, at commit > 87e774825b779ba846315a8b2ffe6479dd9f9814. This should implement your > suggestion already, it was only reverted since there continued to be > complaints of brokenness. > > It is my feeling that his patch was correct, and that the problems noted > were by users who had recreated a wallet during the 34-hour window where the > cipher was broken for all (due to commit > b3a95ba0540e01a9bb10db53fc449cc49ce9a9e8 activating Q_BYTE_ORDER checks in > reverse). If wallets generated in this window are broken then they would > always be treated as corrupt by correct code. But note that the current > autotest only checks the cipher for compliance against Blowfish's own test > vectors, not whether wallets generated using it can be reopened later. > > Pino Toscano wrote: > Apologies for the late reply. > > > If you can test a patch, I'd recommend Allen Winter's last fix attempt > before the whole thing was reverted, at commit > 87e774825b779ba846315a8b2ffe6479dd9f9814. > > If I backport b3a95ba0540e01a9bb10db53fc449cc49ce9a9e8 and > 87e774825b779ba846315a8b2ffe6479dd9f9814 for > `src/runtime/kwalletd/backend/blowfish.cc`, then indeed the test passes on > ppc. Should I go for this, and commit these bits? > > I wonder also about the sha1 code > (`src/runtime/kwalletd/backend/sha1.cc`): ideally this should go away and be > replaced by `QCryptographicHash`, but it's an exported class... So let's > migrate all its usages to `QCryptographicHash` and deprecate it?
> Should I go for this, and commit these bits? If you do, be prepared for bug reports from folks who can no longer open their wallets. Make sure you can tell them how to deal with this, preferably without losing all their data. - Allen ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127833/#review95717 ----------------------------------------------------------- On May 8, 2016, 12:10 a.m., Michael Pyne wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/127833/ > ----------------------------------------------------------- > > (Updated May 8, 2016, 12:10 a.m.) > > > Review request for KDE Frameworks. > > > Repository: kwallet > > > Description > ------- > > This is a collection of minor fixes: > > An uninit variable usage was noted by Coverity (CID 1289177) for a CBC crypto > function, though it only happens for encryption lengths that would not be hit > in practice. I troubleshot this in December but forgot to make a RR, but IIRC > the lengths that would cause problems are 7 bytes or less -- but it's still > better to fix. > > The other Coverity fix is to avoid a needless dup(2) of an opened socket > since it's immediately turned into a FILE* object anyways (CID 1353007). This > avoids a minor resource leak of a file descriptor. > > Finally, some of the ciphers use Qt checks for endianness, and need to > actually include the header that does this instead of relying on other parts > of the code incidentally pulling in the needed #includes. > > > Diffs > ----- > > src/runtime/kwalletd/backend/cbc.cc 4c13466 > src/runtime/kwalletd/main.cpp 90c60d8 > > Diff: https://git.reviewboard.kde.org/r/127833/diff/ > > > Testing > ------- > > Everything still compiles -- I'm limited in my ability to test since I'm > still using KDE4's KWallet (as the KF5 stuff seems to require polkit to > actually work, which isn't possible with a homedir install like mine). > > > Thanks, > > Michael Pyne > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
