On Saturday 24 June 2006 12:11, Robert Nelson wrote: > I can't remember exactly what the signatures in the catalog are used for. > Is it just verification of files on tape and to monitor which files on the > disk might have changed? If that is the case then I don't see any reason > for the Old option either.
They are used for doing verification jobs. However, those that are need for verification can easily be re-written using a level=InitCatalog. The other signatures are stored so that the last backup can be quickly "compared" to the contents of the file to verify if the file data has changed or not. However, this feature has not been implemented within Bacula, only by some users with external software. Finally, the signatures *will* play an important role in Base jobs, but the code is not written. So the bottom line is that the signatures will be out of sync, but it is not serious. > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf > > Of Kern Sibbald > > Sent: Saturday, June 24, 2006 2:18 AM > > To: Robert Nelson > > Cc: [EMAIL PROTECTED]; 'bacula-users'; > > 'Joshua J. Kugler' > > Subject: Re: [Bacula-devel] Protocol Versioning (WAS Re: CVS warning) > > > > On Saturday 24 June 2006 10:57, Robert Nelson wrote: > > > 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. > > > > I don't have any problem with the above, which is essentially > > what my thoughts > > on the subject were (are). However, IMO, there is no need to > > provide the > > Old. If we do decide to go to the new (standard) algoritm > > (except it doesn't > > pad with =, which is not required), I would say we should > > transition and not > > keep the old algorithm around. > > > > The slight disadvantage of not having the Old option is that > > the database > > values are invalidated. > > > > Concerning security: I'm not worried about accepting both > > hash codes (we try > > the new one, and if it failes, try the old algorithm). The > > security issues > > seem pretty minimal to me here. However, my big concern is > > that it is now > > easier for inexperienced users to generate valid > > authentication codes with > > the new algorithm. > > > > By the way, I just finish "hardening" the FD. When *any* > > authentication > > problem is found, it now single threads through a common exit > > point that > > forces all failures to wait 6 seconds. This should > > effectively eliminate any > > possible DOS or brute force attacks. There was always a wait > > after an > > authentication failure, but it was not single threaded and I > > see that not all > > the code systematically passed through the choke point ... > > > > > > -----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 > > > > -- > > 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 -- 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 Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
