Why not have a configuration option like HashVersion or HashCompatibility or
something that can be three values corresponding to Old, Transition, New?
Old
Behaves exactly as it does today and is the default for upgrades.
Transition
Writes the DB using the new hash and attempts authentication first
using the new algorithm then falls back to the old algorithm if that fails.
New
Uses the new algorithm exclusively.
I remember there was some previous discussion regarding accepting both being
a security problem. But I don't think the risk is that high particularly if
it is confined to the period while upgrades are taking place.
When and if a site wants to upgrade their hash they set the value to
Transition. Once all the clients are upgraded they change it to new.
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Kern Sibbald
> Sent: Saturday, June 24, 2006 1:40 AM
> To: Joshua J. Kugler
> Cc: [EMAIL PROTECTED]; bacula-users
> Subject: Re: [Bacula-devel] Protocol Versioning (WAS Re: CVS warning)
>
> 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-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/bacula-devel
>
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
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
