Hello,
Along the lines of protocol versioning and daemon compatibility (I'm sort of
hijacking your thread Joshua ...), there is a *BIG* issue coming up for
version 1.40.0 (when 1.39.x is released), and that is the compatibility of
the Bacula binary base64 routines.
When I wrote the base64 routines (used for "compressing" certain data in the
catalog), the was an RFC, which I used. Then I needed a routine that
converted binary data into base64. Apparently there was also an RFC, though
I have never seen it, and I believe it is part of the email mime stuff so
would not have been so obvious.
The bottom line is that the current bin_to_base64 routine used in Bacula mixes
the bits slightly differently from the algorithm used by other programs (Perl,
Python, ...). swegener in Bacula bug 565 provided a patch that makes the
Bacula alogrithm compatible with the rest of the world.
This bin-to-base64 code is used in two important places: 1. authentication.
2. the hash signatures of file data (used for verify, ...). If the algorithm
is changed, all daemons must be updated at the same time, and the current
hash signatures that are in the database will all be wrong.
The code to "correct" the encoding is already in version 1.39 in the
current CVS. For the moment, the code is on a global switch, which is set to
reproduce the old behavior.
==============!!!!!!!!!!!!!!!!!!!!=====================
The real issue here is that if we change this algorithm, it will make all
authentication incompatible with the prior algorithm. This could be a major
problem for users that have 50 or 60 Bacula clients. For them it is
virtually impossible to upgrade simultaneously.
So for those who would like to see Bacula compatible in the bin-to-base64
routine, the way to ensure that
it gets implemented in Bacula is to upgrade the current authentication
handshake in a compatible way so that (at least for some time) Bacula can run
both algorithms -- i.e. authenticate a client with either the old or new
algorithm. In fact, I would like to make a major upgrade to this handshake
algorithm so that we can also support SHA1 and other hashing schemes.
The advantages of correcting the algorithm:
1. It is a standard off the shelf algorithm, so interface programs (perl,
php, ...) would be much simpler.
2. Comparison of Bacula hash codes for external use would be simpler (some
people do use Bacula has signatures to compare to existing file content).
The Bacula md6hash program (not built by many people) now records both
hashes.
The disadvantages of correcting the algorithm:
1. It is less secure, because any 10 year old in his garage can start hashing
Bacula authentication tokens.
2. It will (as the current code is written) invalidate *all* daemons. I.e.
*everything* must be upgraded at the same time.
3. All the signatures currently kept in the database will be incorrect and
useless.
There seems to be a lot of interest in this algorithm and in fixing it.
Unlike some software programmers, I have no intention of making an
incompatible change that could block our users, so I have no intention to
turn on the new code unless someone comes up with some code to solve item #2
under the "disadvantages", which I consider the blocker. Item #1 (security)
bothers me, but we can probably deal with it in other was. Item #2 (invalid
database data) also bothers me but is not what I consider a blocker).
If anyone wants to work on this, let me know I will help find a solution for
#2 (or 3 if it interests you).
--
Best regards,
Kern
(">
/\
V_V
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users
