FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 05-01-2011, 01:31 PM
Andreas Metzler
 
Default Crypto consolidation in debian ?

Roger Leigh <rleigh@codelibre.net> wrote:
> On Sun, May 01, 2011 at 02:29:39PM +0200, Andreas Metzler wrote:
[...]
>> Also libgcrypt does not seem to be designed to be used indirectly (via
>> gnutls) without knowing and caring about it. (Threading, secmem).
>> Which is why about 50% of all gnutls-using packages are using
>> gcry_control.

> This is the root cause, I think. libgcrypt was developed as part of
> gnutls, and although it's a separate library, it's insufficiently
> generalised. It's implicitly doing things the way gnutls wanted them
> doing,
[...]

I am not sure, but afaik the primary target for libgcrypt was
gnupg(2). gnutls happened later. libgcrypt is not developed as part of
gnutls, there are different upstream authors.

cu andreas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: ju3098-hem.ln1@argenau.downhill.at.eu.org">http://lists.debian.org/ju3098-hem.ln1@argenau.downhill.at.eu.org
 
Old 05-01-2011, 03:38 PM
Simon Josefsson
 
Default Crypto consolidation in debian ?

Roger Leigh <rleigh@codelibre.net> writes:

> This is the root cause, I think. libgcrypt was developed as part of
> gnutls, and although it's a separate library, it's insufficiently
> generalised. It's implicitly doing things the way gnutls wanted them
> doing, and rather than making the library completely general and
> moving special case logic into the callers (or only doing it upon
> specific request), we're in the situation we have now: breakage.

Libgcrypt was designed for GnuPG, not GnuTLS. Btw, for these and other
reasons, recent versions of GnuTLS support the GNU Nettle backend as
well as Libgcrypt. It would be great if Debian could move to it,
although GNU Nettle depends on GMP which is LGPLv3+.

/Simon


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87k4eazb0w.fsf@latte.josefsson.org">http://lists.debian.org/87k4eazb0w.fsf@latte.josefsson.org
 
Old 05-02-2011, 07:50 AM
Josselin Mouette
 
Default Crypto consolidation in debian ?

Le dimanche 01 mai 2011 * 14:08 +0100, Roger Leigh a écrit :
> This is something I can understand to an extent. Having a single
> service providing access to the NSS databases would offer some
> advantages. Unfortunately, I've only ever heard bad things about
> nscd. If we could move to having a central service, rather than
> having every process load in a pile of extra libraries, I would
> probably be in favour of it. If would make some things, such as
> NSS queries inside chroots, much more efficient and robust.
>
> However... that's not the reality right now, and it never has been.

Ever heard of sssd?

I’m asking, because it does precisely the kind of things you are looking
for.

--
.'`. Josselin Mouette
: :' :
`. `'
`-


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1304322630.3293.160.camel@pi0307572">http://lists.debian.org/1304322630.3293.160.camel@pi0307572
 
Old 05-08-2011, 07:13 PM
Arthur de Jong
 
Default Crypto consolidation in debian ?

On Sun, 2011-05-01 at 14:08 +0100, Roger Leigh wrote:
> If we could move to having a central service, rather than having every
> process load in a pile of extra libraries, I would probably be in
> favour of it. If would make some things, such as NSS queries inside
> chroots, much more efficient and robust.

This is what nss-pam-ldapd does to replace nss_ldap (NSS part in
libnss-ldapd). It uses a central daemon running as a dedicated user (for
LDAP NSS requests only). The original reason for the creation of
nss-ldapd was that the OpenLDAP libraries are not meant to be in
processes that do not expect them. I guess there are more.

Another solution (that Joss already pointer out) is libnss-sss which has
a slightly broader scope.

I'm not sure that having a central process to read stuff from simple
flat files is a good idea though as it adds extra complexity and a
single point of failure.

--
-- arthur - adejong@debian.org - http://people.debian.org/~adejong --
 
Old 05-08-2011, 07:25 PM
Arthur de Jong
 
Default Crypto consolidation in debian ?

On Sun, 2011-05-01 at 12:55 +0200, Bastien ROUCARIES wrote:
> It seems fedora is moving to nss for openldap

I don't think it's completely free from the same kind of issues as
GNUTLS. For example, I recently came across this:
https://bugzilla.redhat.com/show_bug.cgi?id=701587
NSS (Network Security Service, not Name Service Switch) seems to change
the scheduling parameters of a process.

Also OpenLDAP itself isn't that good a candidate to load into every
process. Just look at all the hacks nss_ldap needs to do keep it in a
sane state. Also environment variables and files in user's home
directory influence libldap's workings.

Although switching SSL/TLS library to something different may be a good
idea, I don't think it will fix the problem for NSS (Name Service Switch
here) modules.

--
-- arthur - adejong@debian.org - http://people.debian.org/~adejong --
 
Old 05-08-2011, 08:11 PM
Ben Hutchings
 
Default Crypto consolidation in debian ?

On Sun, 2011-05-08 at 21:25 +0200, Arthur de Jong wrote:
> On Sun, 2011-05-01 at 12:55 +0200, Bastien ROUCARIES wrote:
> > It seems fedora is moving to nss for openldap
>
> I don't think it's completely free from the same kind of issues as
> GNUTLS. For example, I recently came across this:
> https://bugzilla.redhat.com/show_bug.cgi?id=701587
> NSS (Network Security Service, not Name Service Switch) seems to change
> the scheduling parameters of a process.
[...]

Scheduling parameters generally apply to a *thread*, not a process.
There is nothing wrong with a library changing those parameters for its
own thread. (However, creating new threads that the application doesn't
know about it can bring its own problems. It is common practice on
Windows and has led to some nasty bugs and workarounds there.)

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
 
Old 05-08-2011, 10:45 PM
Enrico Weigelt
 
Default Crypto consolidation in debian ?

* Arthur de Jong <adejong@debian.org> schrieb:

> Another solution (that Joss already pointer out) is libnss-sss which has
> a slightly broader scope.

In the long run, IMHO, it would be best to move everything
(besides reading local flat files) into its own daemon and
remove the whole plugin stuff from glibc and pam. That would
also solve the static linking problem.

Perhaps something like Plan9's factotum ?


cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/

phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110508224557.GN25423@nibiru.local">http://lists.debian.org/20110508224557.GN25423@nibiru.local
 
Old 05-08-2011, 10:47 PM
Enrico Weigelt
 
Default Crypto consolidation in debian ?

* Arthur de Jong <adejong@debian.org> schrieb:

> Although switching SSL/TLS library to something different may be a good
> idea, I don't think it will fix the problem for NSS (Name Service Switch
> here) modules.

Having the whole SSL/TLS handling in an separate daemon would
be a fine idea. Maybe even as an synthentic filesystem. The
interesting question is how this behaves on high-load scenarios.


cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/

phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110508224757.GO25423@nibiru.local">http://lists.debian.org/20110508224757.GO25423@nibiru.local
 
Old 05-19-2011, 12:18 PM
Ian Jackson
 
Default Crypto consolidation in debian ?

Steve Langasek writes ("Re: Crypto consolidation in debian ?"):
> Changing the uid of the calling application is *not* an acceptable side
> effect for a library and I can't imagine how anyone could believe that it
> is. Unfortunately that seems to leave nss_ldap caught between an SSL
> implementation with a perverse license, and an SSL implementation whose
> upstream has perverse ideas about library handling of process state.

This is free software, right ? We could simply fix our gcrypt.

To avoid accidentally introducing security problems, we could have our
gcrypt read a global variable set by calling programs or libraries, or
something.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 19925.2731.458099.135810@chiark.greenend.org.uk">h ttp://lists.debian.org/19925.2731.458099.135810@chiark.greenend.org.uk
 
Old 03-20-2012, 05:23 PM
Thomas Koch
 
Default Crypto consolidation in debian ?

Bastien ROUCARIES:
> Dear dd,
>
> I have seen that fedora is trying to consolidate the number of crypto
> package shipped [1]. What do you think about this goal ?
>
> Moreover a lot of keyring solution are available for the desktop but
> are not directly compatible between them, and is near a nightmare (for
> instance mozilla is not compatible with kde pinning that is not
> compatible with gnome). This goal is one of the first step to offer a
> common framework for crypto and keyring unification.
>
> Comments welcome.
>
> Bastien
>
> [1]http://fedoraproject.org/wiki/FedoraCryptoConsolidation

Hi,

today I learned the hard way, that cryptography on linux is kind of a mess. I
installed certificates in /usr/local/share/ca-certificates as described in the
README of ca-certificates. - And then I thought that icedove and KMail and the
rest of the world would just use the certificates... :-)

I've opened http://wiki.debian.org/Cryptography because there doesn't seem to
be much of cryptography info on the Debian wiki. Maybe the README in ca-
certificates should point out that matters aren't as easy as suggested.

Regards,

Thomas Koch, http://www.koch.ro


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201203201923.30314.thomas@koch.ro">http://lists.debian.org/201203201923.30314.thomas@koch.ro
 

Thread Tools




All times are GMT. The time now is 11:17 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org