On Sunday 03 December 2006 19:46, Landon Fuller wrote: > > On Dec 3, 2006, at 7:26 AM, Kern Sibbald wrote: > > > I'm still targeting it before the end of the year, but it looks > > like one major > > new feature will not be enabled, and that is data encryption. The > > code just > > is not stable (it doesn't pass a simple regression test), and it > > affects the > > Volume data format, and it has known bugs (digest problems), which > > means that > > if any fixes involve changing the data format (as one does that I > > found this > > morning), it will create incompatible Bacula Volumes. This have never > > happened before in the 7 years of Bacula's existence. > > > > The bottom line is that unless I have a definitive solution (i.e. a > > bug fix > > rather than a rewrite) to the remaining encryption problems by next > > Friday, 8 > > December, it will most probably not be a Bacula feature until much > > later (mid > > to late 2007). > > > > One alternative solution is to postpone the release of version 1.40 > > until late > > March 2007. Since in all other respects 1.40 is ready to go it > > would be a > > shame to postpone the release any longer. Obviously as with all > > new releases > > there is the possibility of a few bugs particularly in the new > > features, but > > there should be no show stoppers such as Volume format > > incompatibility that > > are present in the encryption code. > > It would be negligent of me if this feature isn't ready for release; > what are the remaining blockers that you are concerned about?
Well, for example, the digest/signature routines were passing sparse blocks (blocks that do not exist and are read as zeros) to the digest routine. These blocks are not written to the tape, so in doing a restore, the digest/signature will not match because those sparse blocks are never seen. I fixed this particular problem. There were also reports from some users (and if I am not mistaken, you confirmed them or were at least going to look into it) that reported digest/signature problems. There is also a sort of inconsistency in how the new record size is prepended to records written to the Volume. Each record that is passed to update is prepended with the length, but there is no such length prepended to the finalize call, which means that when reading the records back, the last block length for a data record will not point to a block length but into encrypted data (if all goes well, it will point past the last real byte of data). > What is the remaining (potential?) volume format incompatibility? The current algorithm that is implemented in restore.c is not working -- possibly because of the problem with prepended record lengths, or possibly due to the fact that the code decrypts at times in 16 byte chunks, which has nothing to do with the actual records it is getting. In any case, some data is not restored correctly. This means that there is a possibility that the data is not being written to the volume correctly or that we need more data on the volume (i.e. the last length record I mentioned above). As far as I can tell the restore code decodes the same data for some records twice. The above constitues the notes I said I would write up for you. > > -landonf > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
