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
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
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
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.
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 is an odd
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
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
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 the open source community is
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 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 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 libldap
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 why
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 this
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 does
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 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 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?
I
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
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 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
applications
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 right and it
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 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.
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 to
On Tue, 2013-04-09 at 11:13 -0500, Simon Fondrie-Teitler wrote:
Carlos Alberto Lopez Perez clo...@igalia.com 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
Hi,
Carlos Alberto Lopez Perez clo...@igalia.com 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
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
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]
28 matches
Mail list logo
