Re: SHA1 implementation by Steve Reid

Ian Jackson writes: > The main point of my message, which you are replying to, was that: > this is pointless makework. > If I were the Bacula maintainer I would drop the sha*.[ch]-related > Debian delta, in my next upload, based on the arguments I make in this >

Re: SHA1 implementation by Steve Reid

Carsten Leonhardt writes ("Re: SHA1 implementation by Steve Reid"): > Ian Jackson <ijack...@chiark.greenend.org.uk> writes: > > And, if at any point in the future somebody takes a more legalistic > > view and starts sending takedown notices, we can just throw away

Re: SHA1 implementation by Steve Reid

Ian Jackson writes: > And, if at any point in the future somebody takes a more legalistic > view and starts sending takedown notices, we can just throw away our > existing version based on the old RFC's code and redo the integration > using the nearly-identical

Re: SHA1 implementation by Steve Reid

Florian Weimer writes: > * Carsten Leonhardt: > >> Florian Weimer writes: >> >>> The apparent intent, as evidenced by the copyright statement in the >>> source code parts of RFC 6234, is that the code parts are available >>> under that licensing option,

Re: SHA1 implementation by Steve Reid

* Carsten Leonhardt: > Florian Weimer writes: > >> The apparent intent, as evidenced by the copyright statement in the >> source code parts of RFC 6234, is that the code parts are available >> under that licensing option, even though they are not otherwise marked >> as code

SHA1 implementation by Steve Reid

Hi, the bacula upstream sources contain the SHA1 implementation from the RFC. For the Debian packages, we delete the files sha1.* and repackage the source (for the complete history, see bug #658326). Using codesearch, I found that other packages use the implementation by Steve Reid and submitted