On Sat, 20 Apr 2013 20:18, clo...@igalia.com said:
> Are you planning to merge it upstream?
Sure. Unfortunately I released 1.5.2 just a few days ago. Thus it
won't happen in the next few weeks.
> I believe it will be useful for everyone that asked for this feature on
> the past and ended worka
On 20/04/13 20:18, Carlos Alberto Lopez Perez wrote:
> So, we have the following chain of successes:
^ events
>
> sudo/passwd/su/etc -> libpam ---(if system==PAM/LDAP)--> libpam-ldap ->
> libldap ---(if URI==ldaps://)--> gnutls -> libgcrypt
signature.asc
De
On 20/04/13 02:04, Werner Koch wrote:
> On Sat, 20 Apr 2013 01:35, clo...@igalia.com said:
>
>> I think it would be a good idea to add this feature to libgcrypt.
>
> See attached patch against master. It is not tested, though. You may
> backport it to 1.5 and use it like this:
>
> #if GCRYPT_V
On Sat, 20 Apr 2013 01:35, clo...@igalia.com said:
> I think it would be a good idea to add this feature to libgcrypt.
See attached patch against master. It is not tested, though. You may
backport it to 1.5 and use it like this:
#if GCRYPT_VERSION_NUMBER > 0x010502
gcry_control (GCRYCTL_DI
On 20/04/13 00:08, Werner Koch wrote:
>> At least, I think that you should consider adding a new flag to
>> > libgcrypt that allows the application/library developer to complete
>> > disable the dropping privileges feature. Perhaps something like:
> That was my suggesttion. Shall we go for that?
>
On Fri, 19 Apr 2013 22:37, clo...@igalia.com said:
> They just call a standard function (ex: getpwent). This function may or
> may not chain with libgcrypt depending on how the system libraries are
> compiled and how the system is configured.
Okay, then it is the fault of the libnss code to allow
On 19/04/13 20:56, Werner Koch wrote:
> Having said this, I don't see a reason why not to put the
> responsibilities in the hands of the suid program authors. They anyway
> wake up every night due to a nightmare telling them to check this and
> that and - oh - I am using a library I didn't checked
On Fri, 19 Apr 2013 19:25, jcris...@debian.org said:
> If that "solution" is to have sudo itself call into libgcrypt, that
> doesn't sound like a solution at all. sudo doesn't know how libldap
> implements crypto, it doesn't care, and it shouldn't have to care IMO.
Uh-oh. A suid program that do
On Fri, 19 Apr 2013 20:15, clo...@igalia.com said:
> What about removing this feature of dropping privileges from libgcrypt
> and adding it to gpg itself? gpg could check if is run suid and drop
I already explained that this is not possible because we can't know the
applications which rely on thi
On 19/04/13 10:22, Werner Koch wrote:
> While we are in the business of refreshing our URL memories, let me
> follow up with:
>
> http://thread.gmane.org/gmane.comp.encryption.gpg.libgcrypt.devel/2198
>
> Florian Weimer comes to the same conclusion regarding the PAM
> architecture but also asked
On 19/04/13 19:25, Julien Cristau wrote:
> On Fri, Apr 19, 2013 at 19:07:02 +0200, Werner Koch wrote:
>
>> What about my suggestion on how to solve the problem?
>>
> If that "solution" is to have sudo itself call into libgcrypt, that
> doesn't sound like a solution at all. sudo doesn't know how l
On Fri, Apr 19, 2013 at 19:07:02 +0200, Werner Koch wrote:
> What about my suggestion on how to solve the problem?
>
If that "solution" is to have sudo itself call into libgcrypt, that
doesn't sound like a solution at all. sudo doesn't know how libldap
implements crypto, it doesn't care, and it
On Fri, 19 Apr 2013 18:54, clo...@igalia.com said:
> I couldn't find anything relevant on the archives.
Next step would be to check the repos and all packages using Libgcrypt.
> Saying that there is a good reason for this commit to be there and at
> the same time saying that such good reason is
On 19/04/13 10:22, Werner Koch wrote:
> On Fri, 19 Apr 2013 02:52, mgilb...@debian.org said:
>>> 1.a) Patch libgcrypt to revert commit
>>> d769529a71ccda4e833f919f3c5693d25b005ff0
>>> >>
>>> >> Urgs. That is a short sighted fix.
>> >
>> > That seems to be the solution the rest of th
Werner Koch wrote:
On Fri, 19 Apr 2013 09:22, h...@symas.com said:
Frankly, speaking for the OpenLDAP Project, what we want is to delete
all support for GnuTLS. It is, like Mozilla NSS, a poorly designed API
Split OpenLDAP into a daemon and a simple access library and things
would be more robu
On Fri, 19 Apr 2013 09:22, h...@symas.com said:
> Excuse me? By what measure is this correct? Certainly not by any
> published official documentation.
The correct solution is to let the application handle this. But I don't
want to repeat this now. "most correct" here means, it is not worse
than
On Fri, 19 Apr 2013 02:52, mgilb...@debian.org said:
>>> 1.a) Patch libgcrypt to revert commit
>>> d769529a71ccda4e833f919f3c5693d25b005ff0
>>
>> Urgs. That is a short sighted fix.
>
> That seems to be the solution the rest of the open source community is
> converging toward. Short sighted i
Werner Koch wrote:
On Thu, 18 Apr 2013 20:40, clo...@igalia.com said:
I see two options to get this fixed for Wheezy:
[Option 1] -- Do the same that Ubuntu did. That is:
1.a) Patch libgcrypt to revert commit
d769529a71ccda4e833f919f3c5693d25b005ff0
Urgs. That is a short sighted fix.
>> 1.a) Patch libgcrypt to revert commit
>> d769529a71ccda4e833f919f3c5693d25b005ff0
>
> Urgs. That is a short sighted fix.
That seems to be the solution the rest of the open source community is
converging toward. Short sighted is an odd categorization since it
seems to have taken 8 years t
On Thu, 18 Apr 2013 20:24, a...@adam-barratt.org.uk said:
> GnuTLS 3 isn't particularly relevant to getting this RC bug fixed in
> wheezy, given that wheezy will be shipping with 2.12.
It also ships 3.0 (libgnutls28) which then sometimes leads tp processes
linking two different versions of GNUTLS
On Thu, 18 Apr 2013 20:40, clo...@igalia.com said:
> I see two options to get this fixed for Wheezy:
>
> [Option 1] -- Do the same that Ubuntu did. That is:
>
> 1.a) Patch libgcrypt to revert commit
> d769529a71ccda4e833f919f3c5693d25b005ff0
Urgs. That is a short sighted fix.
> [Option 2]
On 18/04/13 20:24, Adam D. Barratt wrote:
> On Thu, 2013-04-18 at 18:58 +0200, Werner Koch wrote:
>> On Tue, 16 Apr 2013 20:37, a...@adam-barratt.org.uk said:
>>
>>> libgcrypt maintainers - any thoughts on this?
>>
>> Did anything change since my comments from 2010?
>>
>> OpenLDAP needs to get it r
On Thu, 2013-04-18 at 18:58 +0200, Werner Koch wrote:
> On Tue, 16 Apr 2013 20:37, a...@adam-barratt.org.uk said:
>
> > libgcrypt maintainers - any thoughts on this?
>
> Did anything change since my comments from 2010?
>
> OpenLDAP needs to get it right and it would even be better if all
> appli
On Tue, 16 Apr 2013 20:37, a...@adam-barratt.org.uk said:
> libgcrypt maintainers - any thoughts on this?
Did anything change since my comments from 2010?
OpenLDAP needs to get it right and it would even be better if all
applications would set up a their policy regarding their demand for
private
On Tue, 2013-04-09 at 11:13 -0500, Simon Fondrie-Teitler wrote:
> Carlos Alberto Lopez Perez writes:
> > Therefore I think we should reassign this bug back to libgcrypt11. Fix
> > it with a patch that reverts d769529a71ccda4e833f919f3c5693d25b005ff0
> > [1] and then fill another RC bug for python-
Hi,
Carlos Alberto Lopez Perez writes:
> Now I'm convinced that the right fix for this is to revert upstream
> d769529a71ccda4e833f919f3c5693d25b005ff0 [1] commit on libgcrypt like
> Ubuntu did.
>
> The Regression introduced on python-gnutls by such reversion was already
> fixed on Ubuntu with a
On 03/04/13 10:43 AM, Carlos Alberto Lopez Perez wrote:
Furthermore libgcrypt upstream seems to be ok with this change, isn't
it? [3]
Thanks for finding this upstream thread Carlos! And for your work
earlier where you spotted the 2005 upstream commit.
[3] http://thread.gmane.org/gmane.comp.
On 03/04/13 16:09, Jack Bates wrote:
> Hi, here is a blog post about this issue:
>
> http://jdbates.blogspot.ca/2013/04/its-crazy-how-much-time-and-effort-one.html
>
Really very interesting stuff. Thanks for sharing
Now I'm convinced that the right fix for this is to revert upstream
d769529a71
28 matches
Mail list logo
