Re: [PATCH] Define secure_getenv (v3)

["Carlos O'Donell" <carlos at systemhalted dot org>]

On Mon, Jul 23, 2012 at 9:28 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 07/20/2012 06:43 PM, Roland McGrath wrote:
>>>
>>> Oh, will fix.  Is this about static linking?
>>
>>
>> Today in practice in most cases it only makes a difference for static
>> linking.  That's only because of our arcane PLT avoidance techniques.
>> It's still not the case for references between shared libraries, like
>> a libc function called by libm or librt, etc.
>>
>>> The existing sources do not follow this rule in all cases, so I assumed
>>> it was expendable.
>>
>>
>> The actual rule is more subtle than this.  So it may be that what
>> you've observed are cases that are actually kosher.  If not, then
>> those are bugs and we'd appreciate your reporting (or fixing!) any
>> such cases you noticed.
>
>
> Thanks for the explanation.
>
> ptsname_r (_GNU_SOURCE) is used from openpty (not conditionally defined, but
> BSDish I think).  Would this qualify as treif?
>
> Anyway, I'm attaching version 3 of the patch, which uses
> __libc_secure_getenv internally.  Testing passes on x86_64-redhat-linux-gnu.
> I've verified that existing binaries linked against __secure_getenv still
> run with this version.

This third version looks good to me. You are almost done. Lastly you
need to write
a NEWS entry that will go into the NEWS file and show up in the official release
announcement when we roll out 2.17. As an example see the entry for the addition
of getauxval.

I'm sorry that your patch has gotten so much bigger, but that's the nature of
pulling on loose strings. I hope that the process hasn't been to burdensome, and
that we've provided you with enough feedback to keep it moving.

Cheers,
Carlos.