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
> thread.
Thank you for this very
Carsten Leonhardt writes ("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
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 code from the new RFC.
Hm, the pre
Carsten Leonhardt writes ("Re: SHA1 implementation by Steve Reid"):
> So from what you wrote earlier, I understand that the IETF saw the
> problem with code in RFCs and took steps to clarify the situation, which
> I take as a hint from the IETF that the old code from RFC_3174
&
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, even though they are not otherwise marked
* 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 components under the T
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 components under the TLP.
So in essence the code i
* Carsten Leonhardt:
>> 1. What is wrong with the current SHA1 code/license? For me the
>> license is very much like a BSD license and I don't see a problem with
>> it on the license stand point.
>
> AFAIR the problem is that the RFC is not to be modified, and the code
> came as part of the RFC, s
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
9 matches
Mail list logo
