You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2005/12/07 22:26:19 UTC
Re: svn commit: r354824 - in /apr/apr/trunk/random/unix: sha2.c sha2.h
sha2_glue.c
fitz@apache.org wrote:
> Prefix non-static symbols with 'apr__' to avoid namespace conflicts.
>
> * random/unix/sha2.h, random/unix/sha2_glue.c, random/unix/sha2.c:
> Rename SHA256_Init, SHA256_Update, SHA256_Final, SHA256_Transform,
> SHA384_Init, SHA512_Init, SHA512_Final, SHA384_Final, SHA512_Update,
> SHA384_Update, and SHA512_Transform, , to apr__SHA256_Init,
> apr__SHA256_Update, apr__SHA256_Final, apr__SHA256_Transform,
> apr__SHA384_Init, apr__SHA512_Init, apr__SHA512_Final,
> apr__SHA384_Final, apr__SHA512_Update, apr__SHA384_Update, and
> apr__SHA512_Transform.
Are these in fact 'not for external use'?
If they are for export, why the choice of the extra underbar? Given that we
do export MD5 for everyone's use, and the universal contention is that MD5 is,
if not today, then, dead by tomorrow for most security purposes.
It seems these should be public, and the '__'s will inevitably confuse some
devs, as well as not following our conventions.
Bill
Re: svn commit: r354824 - in /apr/apr/trunk/random/unix: sha2.c sha2.h
sha2_glue.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Brian W. Fitzpatrick wrote:
>
> If they're not in the public headers, I don't think it's a problem.
>
> This is not a big deal--I am correcting an oversight.
+1, and +1 to applying this patch to 1.2 branch in the case of a 1.2.3
release.
And +1 to making this the convention.
I believe we have to rid ourselves of MD5 (so do our dev/users) and therefore
more SHA choices in the public API are very good things. But that change can
absolutely happen -after- this change, which is good in and of itself.
Bill
Re: svn commit: r354824 - in /apr/apr/trunk/random/unix: sha2.c sha2.h
sha2_glue.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Brian W. Fitzpatrick wrote:
>
> If they're not in the public headers, I don't think it's a problem.
>
> This is not a big deal--I am correcting an oversight.
+1, and +1 to applying this patch to 1.2 branch in the case of a 1.2.3
release.
And +1 to making this the convention.
I believe we have to rid ourselves of MD5 (so do our dev/users) and therefore
more SHA choices in the public API are very good things. But that change can
absolutely happen -after- this change, which is good in and of itself.
Bill
Re: svn commit: r354824 - in /apr/apr/trunk/random/unix: sha2.c sha2.h sha2_glue.c
Posted by "Brian W. Fitzpatrick" <fi...@red-bean.com>.
On Dec 7, 2005, at 4:00 PM, William A. Rowe, Jr. wrote:
> Brian W. Fitzpatrick wrote:
>> On Dec 7, 2005, at 3:26 PM, William A. Rowe, Jr. wrote:
>>> fitz@apache.org wrote:
>>>
>>>> Prefix non-static symbols with 'apr__' to avoid namespace
>>>> conflicts.
>>>> * random/unix/sha2.h, random/unix/sha2_glue.c, random/unix/sha2.c:
>>>> Rename SHA256_Init, SHA256_Update, SHA256_Final,
>>>> SHA256_Transform,
>>>> SHA384_Init, SHA512_Init, SHA512_Final, SHA384_Final,
>>>> SHA512_Update,
>>>> SHA384_Update, and SHA512_Transform, , to apr__SHA256_Init,
>>>> apr__SHA256_Update, apr__SHA256_Final, apr__SHA256_Transform,
>>>> apr__SHA384_Init, apr__SHA512_Init, apr__SHA512_Final,
>>>> apr__SHA384_Final, apr__SHA512_Update, apr__SHA384_Update, and
>>>> apr__SHA512_Transform.
>>>
>>> Are these in fact 'not for external use'?
>> That is correct. You may notice that there are no symbols for
>> these functions in APR's public headers.
>
> Correct, but why? ...
*sigh* They're merely meant to be consumed by the yet unfinished
PRNG. Ask Ben Laurie for details.
>>> If they are for export, why the choice of the extra underbar?
>>> Given that we
>>> do export MD5 for everyone's use, and the universal contention
>>> is that MD5 is,
>>> if not today, then, dead by tomorrow for most security purposes.
>
> I didn't see your comment to this, it seems these -should- be
> exported to me.
And I'm telling you that they should NOT be exported.
>>> It seems these should be public, and the '__'s will inevitably
>>> confuse some
>>> devs, as well as not following our conventions.
>> Then we should document it as our convention. :-)
>
> Or something +1... _apr_foo or apr__foo is fine here.
>
> We should also spell out that any such __ entry points are NOT
> subject to our
> revisioning policy, shoot yourself in the foot at your own risk.
If they're not in the public headers, I don't think it's a problem.
This is not a big deal--I am correcting an oversight.
-Fitz
Re: svn commit: r354824 - in /apr/apr/trunk/random/unix: sha2.c sha2.h sha2_glue.c
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 12/7/05, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> I didn't see your comment to this, it seems these -should- be exported to me.
Don't we already have functions in the public API for calculating SHA1 hashes?
> >> It seems these should be public, and the '__'s will inevitably
> >> confuse some
> >> devs, as well as not following our conventions.
> >
> > Then we should document it as our convention. :-)
>
> Or something +1... _apr_foo or apr__foo is fine here.
Actually, _apr_foo is not fine, leading underscores are in the C
library's implementation namespace IIRC.
-garrett
Re: svn commit: r354824 - in /apr/apr/trunk/random/unix: sha2.c sha2.h sha2_glue.c
Posted by "Brian W. Fitzpatrick" <fi...@red-bean.com>.
On Dec 7, 2005, at 4:00 PM, William A. Rowe, Jr. wrote:
> Brian W. Fitzpatrick wrote:
>> On Dec 7, 2005, at 3:26 PM, William A. Rowe, Jr. wrote:
>>> fitz@apache.org wrote:
>>>
>>>> Prefix non-static symbols with 'apr__' to avoid namespace
>>>> conflicts.
>>>> * random/unix/sha2.h, random/unix/sha2_glue.c, random/unix/sha2.c:
>>>> Rename SHA256_Init, SHA256_Update, SHA256_Final,
>>>> SHA256_Transform,
>>>> SHA384_Init, SHA512_Init, SHA512_Final, SHA384_Final,
>>>> SHA512_Update,
>>>> SHA384_Update, and SHA512_Transform, , to apr__SHA256_Init,
>>>> apr__SHA256_Update, apr__SHA256_Final, apr__SHA256_Transform,
>>>> apr__SHA384_Init, apr__SHA512_Init, apr__SHA512_Final,
>>>> apr__SHA384_Final, apr__SHA512_Update, apr__SHA384_Update, and
>>>> apr__SHA512_Transform.
>>>
>>> Are these in fact 'not for external use'?
>> That is correct. You may notice that there are no symbols for
>> these functions in APR's public headers.
>
> Correct, but why? ...
*sigh* They're merely meant to be consumed by the yet unfinished
PRNG. Ask Ben Laurie for details.
>>> If they are for export, why the choice of the extra underbar?
>>> Given that we
>>> do export MD5 for everyone's use, and the universal contention
>>> is that MD5 is,
>>> if not today, then, dead by tomorrow for most security purposes.
>
> I didn't see your comment to this, it seems these -should- be
> exported to me.
And I'm telling you that they should NOT be exported.
>>> It seems these should be public, and the '__'s will inevitably
>>> confuse some
>>> devs, as well as not following our conventions.
>> Then we should document it as our convention. :-)
>
> Or something +1... _apr_foo or apr__foo is fine here.
>
> We should also spell out that any such __ entry points are NOT
> subject to our
> revisioning policy, shoot yourself in the foot at your own risk.
If they're not in the public headers, I don't think it's a problem.
This is not a big deal--I am correcting an oversight.
-Fitz
Re: svn commit: r354824 - in /apr/apr/trunk/random/unix: sha2.c sha2.h
sha2_glue.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Brian W. Fitzpatrick wrote:
>
> On Dec 7, 2005, at 3:26 PM, William A. Rowe, Jr. wrote:
>
>> fitz@apache.org wrote:
>>
>>> Prefix non-static symbols with 'apr__' to avoid namespace conflicts.
>>> * random/unix/sha2.h, random/unix/sha2_glue.c, random/unix/sha2.c:
>>> Rename SHA256_Init, SHA256_Update, SHA256_Final, SHA256_Transform,
>>> SHA384_Init, SHA512_Init, SHA512_Final, SHA384_Final, SHA512_Update,
>>> SHA384_Update, and SHA512_Transform, , to apr__SHA256_Init,
>>> apr__SHA256_Update, apr__SHA256_Final, apr__SHA256_Transform,
>>> apr__SHA384_Init, apr__SHA512_Init, apr__SHA512_Final,
>>> apr__SHA384_Final, apr__SHA512_Update, apr__SHA384_Update, and
>>> apr__SHA512_Transform.
>>
>> Are these in fact 'not for external use'?
>
> That is correct. You may notice that there are no symbols for these
> functions in APR's public headers.
Correct, but why? ...
>> If they are for export, why the choice of the extra underbar? Given
>> that we
>> do export MD5 for everyone's use, and the universal contention is
>> that MD5 is,
>> if not today, then, dead by tomorrow for most security purposes.
I didn't see your comment to this, it seems these -should- be exported to me.
>> It seems these should be public, and the '__'s will inevitably
>> confuse some
>> devs, as well as not following our conventions.
>
> Then we should document it as our convention. :-)
Or something +1... _apr_foo or apr__foo is fine here.
We should also spell out that any such __ entry points are NOT subject to our
revisioning policy, shoot yourself in the foot at your own risk.
Bill
Re: svn commit: r354824 - in /apr/apr/trunk/random/unix: sha2.c sha2.h
sha2_glue.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Brian W. Fitzpatrick wrote:
>
> On Dec 7, 2005, at 3:26 PM, William A. Rowe, Jr. wrote:
>
>> fitz@apache.org wrote:
>>
>>> Prefix non-static symbols with 'apr__' to avoid namespace conflicts.
>>> * random/unix/sha2.h, random/unix/sha2_glue.c, random/unix/sha2.c:
>>> Rename SHA256_Init, SHA256_Update, SHA256_Final, SHA256_Transform,
>>> SHA384_Init, SHA512_Init, SHA512_Final, SHA384_Final, SHA512_Update,
>>> SHA384_Update, and SHA512_Transform, , to apr__SHA256_Init,
>>> apr__SHA256_Update, apr__SHA256_Final, apr__SHA256_Transform,
>>> apr__SHA384_Init, apr__SHA512_Init, apr__SHA512_Final,
>>> apr__SHA384_Final, apr__SHA512_Update, apr__SHA384_Update, and
>>> apr__SHA512_Transform.
>>
>> Are these in fact 'not for external use'?
>
> That is correct. You may notice that there are no symbols for these
> functions in APR's public headers.
Correct, but why? ...
>> If they are for export, why the choice of the extra underbar? Given
>> that we
>> do export MD5 for everyone's use, and the universal contention is
>> that MD5 is,
>> if not today, then, dead by tomorrow for most security purposes.
I didn't see your comment to this, it seems these -should- be exported to me.
>> It seems these should be public, and the '__'s will inevitably
>> confuse some
>> devs, as well as not following our conventions.
>
> Then we should document it as our convention. :-)
Or something +1... _apr_foo or apr__foo is fine here.
We should also spell out that any such __ entry points are NOT subject to our
revisioning policy, shoot yourself in the foot at your own risk.
Bill
Re: svn commit: r354824 - in /apr/apr/trunk/random/unix: sha2.c sha2.h sha2_glue.c
Posted by "Brian W. Fitzpatrick" <fi...@red-bean.com>.
On Dec 7, 2005, at 3:26 PM, William A. Rowe, Jr. wrote:
> fitz@apache.org wrote:
>> Prefix non-static symbols with 'apr__' to avoid namespace conflicts.
>> * random/unix/sha2.h, random/unix/sha2_glue.c, random/unix/sha2.c:
>> Rename SHA256_Init, SHA256_Update, SHA256_Final, SHA256_Transform,
>> SHA384_Init, SHA512_Init, SHA512_Final, SHA384_Final,
>> SHA512_Update,
>> SHA384_Update, and SHA512_Transform, , to apr__SHA256_Init,
>> apr__SHA256_Update, apr__SHA256_Final, apr__SHA256_Transform,
>> apr__SHA384_Init, apr__SHA512_Init, apr__SHA512_Final,
>> apr__SHA384_Final, apr__SHA512_Update, apr__SHA384_Update, and
>> apr__SHA512_Transform.
>
> Are these in fact 'not for external use'?
That is correct. You may notice that there are no symbols for these
functions in APR's public headers.
> If they are for export, why the choice of the extra underbar?
> Given that we
> do export MD5 for everyone's use, and the universal contention is
> that MD5 is,
> if not today, then, dead by tomorrow for most security purposes.
>
> It seems these should be public, and the '__'s will inevitably
> confuse some
> devs, as well as not following our conventions.
Then we should document it as our convention. :-)
-Fitz
Re: svn commit: r354824 - in /apr/apr/trunk/random/unix: sha2.c sha2.h sha2_glue.c
Posted by "Brian W. Fitzpatrick" <fi...@red-bean.com>.
On Dec 7, 2005, at 3:26 PM, William A. Rowe, Jr. wrote:
> fitz@apache.org wrote:
>> Prefix non-static symbols with 'apr__' to avoid namespace conflicts.
>> * random/unix/sha2.h, random/unix/sha2_glue.c, random/unix/sha2.c:
>> Rename SHA256_Init, SHA256_Update, SHA256_Final, SHA256_Transform,
>> SHA384_Init, SHA512_Init, SHA512_Final, SHA384_Final,
>> SHA512_Update,
>> SHA384_Update, and SHA512_Transform, , to apr__SHA256_Init,
>> apr__SHA256_Update, apr__SHA256_Final, apr__SHA256_Transform,
>> apr__SHA384_Init, apr__SHA512_Init, apr__SHA512_Final,
>> apr__SHA384_Final, apr__SHA512_Update, apr__SHA384_Update, and
>> apr__SHA512_Transform.
>
> Are these in fact 'not for external use'?
That is correct. You may notice that there are no symbols for these
functions in APR's public headers.
> If they are for export, why the choice of the extra underbar?
> Given that we
> do export MD5 for everyone's use, and the universal contention is
> that MD5 is,
> if not today, then, dead by tomorrow for most security purposes.
>
> It seems these should be public, and the '__'s will inevitably
> confuse some
> devs, as well as not following our conventions.
Then we should document it as our convention. :-)
-Fitz