Re: Crypto consolidation in debian ?

2012-03-20 Thread Thomas Koch 
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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201203201923.30314.tho...@koch.ro

Re: Crypto consolidation in debian ?

2011-07-23 Thread Enrico Weigelt 
* Arthur de Jong  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: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110508224757.GO25423@nibiru.local

Re: Crypto consolidation in debian ?

2011-07-23 Thread Enrico Weigelt 
* Arthur de Jong  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: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110508224557.GN25423@nibiru.local

Re: Crypto consolidation in debian ?

2011-05-19 Thread Ian Jackson 
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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/19925.2731.458099.135...@chiark.greenend.org.uk

Re: Crypto consolidation in debian ?

2011-05-08 Thread Ben Hutchings 
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.


signature.asc
Description: This is a digitally signed message part

Re: Crypto consolidation in debian ?

2011-05-08 Thread Arthur de Jong 
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 - adej...@debian.org - http://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Re: Crypto consolidation in debian ?

2011-05-08 Thread Arthur de Jong 
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 - adej...@debian.org - http://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Re: Crypto consolidation in debian ?

2011-05-02 Thread Josselin Mouette 
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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1304322630.3293.160.camel@pi0307572

Re: Crypto consolidation in debian ?

2011-05-01 Thread Simon Josefsson 
Roger Leigh  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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k4eazb0w@latte.josefsson.org

Re: Crypto consolidation in debian ?

2011-05-01 Thread Andreas Metzler 
Roger Leigh  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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ju3098-hem@argenau.downhill.at.eu.org

Re: Crypto consolidation in debian ?

2011-05-01 Thread Andreas Barth 
* Roger Leigh (rle...@codelibre.net) [110501 15:08]:
> Even if the NSS situation changes, surely it's immediately obvious
> that a random library function should not tamper with the uid of a
> process as a side-effect?  Unless the caller explicitly requested
> dropping of root privs, no library has *any* business in changing it.

I miss (not only here) the principle:
 First, do no harm.

Which are totally failed by a library changing uids on it's own.



Andi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110501131714.ge15...@mails.so.argh.org

Re: Crypto consolidation in debian ?

2011-05-01 Thread Andreas Metzler 
Andreas Metzler  wrote:

> Also libgcrypt does seem to be designed to be used indirectly
 ^
 |
not


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/vi2098-aul@argenau.downhill.at.eu.org

Re: Crypto consolidation in debian ?

2011-05-01 Thread Roger Leigh 
On Sun, May 01, 2011 at 02:29:39PM +0200, Andreas Metzler wrote:
> Simon Josefsson  wrote:
> [...]
> > It appears to be usable by a lot of projects and people, so that seems
> > like an exaggeration.  If I have understood Werner correctly, he
> > believes that it is the setuid binaries that are broken and should be
> > fixed.
> [...]
> 
> Hello,
> I would rather say he considers NSS (or PAM) fundamentally broken,
> because a tiny, scrutinized SUID binary ends up with *huge* amounts of
> external unrelated code in its address space after getpwnam().

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.

Even if the NSS situation changes, surely it's immediately obvious
that a random library function should not tamper with the uid of a
process as a side-effect?  Unless the caller explicitly requested
dropping of root privs, no library has *any* business in changing it.
The reality is that only the main program knows what uid and other
privileges it wants and needs to function; a library can't make any
assumptions about what may or may not be appropriate here.  It could
be instructed by the main program to drop privs, but it can't
unilaterally make that decision on its own, which is what libgcrypt is
doing right now.

> Also libgcrypt does 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, 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.
Using it indirectly is not a solution; the solution is to fix the
library to work sensibly by default, and fix up the client code
relying on the assumptions made by the library so that they can be
removed and/or made non-default.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: Crypto consolidation in debian ?

2011-05-01 Thread Andreas Metzler 
Simon Josefsson  wrote:
[...]
> It appears to be usable by a lot of projects and people, so that seems
> like an exaggeration.  If I have understood Werner correctly, he
> believes that it is the setuid binaries that are broken and should be
> fixed.
[...]

Hello,
I would rather say he considers NSS (or PAM) fundamentally broken,
because a tiny, scrutinized SUID binary ends up with *huge* amounts of
external unrelated code in its address space after getpwnam().

Also libgcrypt does 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.

cu andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ja0098-mlf@argenau.downhill.at.eu.org

Re: Crypto consolidation in debian ?

2011-05-01 Thread Bastien ROUCARIES 
On Sun, May 1, 2011 at 3:23 AM, Steve Langasek  wrote:
> On Thu, Apr 28, 2011 at 03:09:48PM +0200, Simon Josefsson wrote:
>> Roger Leigh  writes:
>
>> > libgcrypt has some horrendous bugs which upstream refuse to fix,
>> > for example the broken behaviour relating to setuid binaries
>> > discussed previously here, and the hard coded behaviour which
>> > makes it unsuitable for use in general programs.  See
>> >
>> > "libgcrypt brain dead?"
>> > 3c5cf5261003081534s5202413dw4d93c80db1a30...@mail.gmail.com
>
>> > Until these major issues are fixed, it's simply unusable.
>
>> It appears to be usable by a lot of projects and people, so that seems
>> like an exaggeration.  If I have understood Werner correctly, he
>> believes that it is the setuid binaries that are broken and should be
>> fixed.
>
> As a comaintainer of openldap, which links to gnutls in Debian for license
> reasons, I need to vehemently echo Roger here.  sudo most certainly isn't
> broken for being setuid, and libgcrypt should definitely not be ripping its
> suid privs out from under it, yet this is what happens if using nss_ldap
> with an SSL-using LDAP server.
>
>  http://bugs.debian.org/566351
>  https://bugs.launchpad.net/bugs/423252
>
> 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.

It seems fedora is moving to nss for openldap

https://fedoraproject.org/wiki/Test_Day:2010-10-14_OpenLDAP/NSS

Have you tested ?

Bastien


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/BANLkTind2XtFLBr5y8_4v=+umfnbzb+...@mail.gmail.com

Re: Crypto consolidation in debian ?

2011-04-30 Thread Steve Langasek 
On Thu, Apr 28, 2011 at 03:09:48PM +0200, Simon Josefsson wrote:
> Roger Leigh  writes:

> > libgcrypt has some horrendous bugs which upstream refuse to fix,
> > for example the broken behaviour relating to setuid binaries
> > discussed previously here, and the hard coded behaviour which
> > makes it unsuitable for use in general programs.  See
> >
> > "libgcrypt brain dead?"
> > 3c5cf5261003081534s5202413dw4d93c80db1a30...@mail.gmail.com

> > Until these major issues are fixed, it's simply unusable.

> It appears to be usable by a lot of projects and people, so that seems
> like an exaggeration.  If I have understood Werner correctly, he
> believes that it is the setuid binaries that are broken and should be
> fixed.

As a comaintainer of openldap, which links to gnutls in Debian for license
reasons, I need to vehemently echo Roger here.  sudo most certainly isn't
broken for being setuid, and libgcrypt should definitely not be ripping its
suid privs out from under it, yet this is what happens if using nss_ldap
with an SSL-using LDAP server.

  http://bugs.debian.org/566351
  https://bugs.launchpad.net/bugs/423252

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.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110501012328.gb22...@virgil.dodds.net

Re: Crypto consolidation in debian ?

2011-04-28 Thread Clint Adams 
On Thu, Apr 28, 2011 at 10:37:37AM +0200, Bastien ROUCARIES wrote:
> So, could we document we different pitfall of crypto library on the
> debian wiki ?

You could use http://curl.haxx.se/docs/ssl-compared.html
and http://en.wikipedia.org/wiki/Comparison_of_TLS_Implementations
as starting points.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110428154931.ga32...@scru.org

Re: Crypto consolidation in debian ?

2011-04-28 Thread Roger Leigh 
On Thu, Apr 28, 2011 at 03:09:48PM +0200, Simon Josefsson wrote:
> Roger Leigh  writes:
> 
> > libgcrypt has some horrendous bugs which upstream refuse to fix,
> > for example the broken behaviour relating to setuid binaries
> > discussed previously here, and the hard coded behaviour which
> > makes it unsuitable for use in general programs.  See
> >
> > "libgcrypt brain dead?"
> > 3c5cf5261003081534s5202413dw4d93c80db1a30...@mail.gmail.com
> >
> > Until these major issues are fixed, it's simply unusable.
> 
> It appears to be usable by a lot of projects and people, so that seems
> like an exaggeration.  If I have understood Werner correctly, he
> believes that it is the setuid binaries that are broken and should be
> fixed.

It is usable if your program meets the hardcoded assumptions made in
libgcrypt.  If it does not, it breaks badly.  This is why it's not
*generally* usable, but only in specific cases.

Werner's assertions WRT setuid binaries are plain wrong.  gcrypt
takes it upon itself to drop setuid privs because it makes the
*assumption* that you are setuid solely to use mlock().  What if
you are setuid for some other reason?  In every other case, gcrypt
drops root privs when you might still want them.  And in the case
that gcrypt is used as a side effect of being linked into an NSS
module, it can happen during many glibc calls.  That is totally
broken.

Example: schroot is setuid and needs to be setuid to chroot() and
setuid() to the specified user.  If you have a NSS module linked
with gcrypt, a simple getpwent call results in a premature dropping
of root privs, and the program subsequently aborts because it no
longer has the privs to do its job.  gcrypt is entirely responsible
for that breakage by making a broken assumption.  It's not the job
of a *library function* to alter *global process state* as a side
effect.

setuid binaries which are setuid solely for mlock() need to drop
root privs themselves, or have some means for them to instruct
gcrypt to drop them explicitly on request.  Doing it by default is
poor practice, and breaks things as that thread shows.  This is a
fundamental design flaw in gcrypt which needs fixing before it is
suitable for general purpose use.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: Crypto consolidation in debian ?

2011-04-28 Thread Simon Josefsson 
m...@linux.it (Marco d'Itri) writes:

> On Apr 27, Bastian Blank  wrote:
>
>> On Tue, Apr 26, 2011 at 07:20:55PM +0200, Marco d'Itri wrote:
>> > The reason is that the kind of entities which require FIPS 140 probably
>> > also tend to require corporate vendor support, which we do not provide.
>> What is FIPS 140 and why is this important?
> It is a certification required by USG and many financial customers.

For what it's worth, libgcrypt was in FIPS evaluation long time ago and
may even be certified by now.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zkna34qf@latte.josefsson.org

Re: Crypto consolidation in debian ?

2011-04-28 Thread Simon Josefsson 
Roger Leigh  writes:

> On Wed, Apr 27, 2011 at 09:30:05AM -0700, Russ Allbery wrote:
>> Bastien ROUCARIES  writes:
>> 
>> >> Patches to WebAuth to support NSS are welcome, but I'm sure not going to
>> >> bother.  Seems like a waste of time to me.  If I were going to port to any
>> >> other crypto library, I'd port to gcrypto, not NSS.
>> 
>> > See also that suse consider to port to nss
>> > http://old-en.opensuse.org/SharedCertStore
>> 
>> That's fine.  They can send me patches too if they want.  :)  I'm still
>> not interested; I'd rather put whatever time I had into making gnutls and
>> gcrypto better, particularly since I think FIPS certification is just a
>> money-making racket.
>
> libgcrypt has some horrendous bugs which upstream refuse to fix,
> for example the broken behaviour relating to setuid binaries
> discussed previously here, and the hard coded behaviour which
> makes it unsuitable for use in general programs.  See
>
> "libgcrypt brain dead?"
> 3c5cf5261003081534s5202413dw4d93c80db1a30...@mail.gmail.com
>
> Until these major issues are fixed, it's simply unusable.

It appears to be usable by a lot of projects and people, so that seems
like an exaggeration.  If I have understood Werner correctly, he
believes that it is the setuid binaries that are broken and should be
fixed.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vcxy34kj@latte.josefsson.org

Re: Crypto consolidation in debian ?

2011-04-28 Thread Bastien ROUCARIES 
On Wed, Apr 27, 2011 at 6:46 PM, Roger Leigh  wrote:
> On Wed, Apr 27, 2011 at 09:30:05AM -0700, Russ Allbery wrote:
>> Bastien ROUCARIES  writes:
>>
>> >> Patches to WebAuth to support NSS are welcome, but I'm sure not going to
>> >> bother.  Seems like a waste of time to me.  If I were going to port to any
>> >> other crypto library, I'd port to gcrypto, not NSS.
>>
>> > See also that suse consider to port to nss
>> > http://old-en.opensuse.org/SharedCertStore
>>
>> That's fine.  They can send me patches too if they want.  :)  I'm still
>> not interested; I'd rather put whatever time I had into making gnutls and
>> gcrypto better, particularly since I think FIPS certification is just a
>> money-making racket.
>
> libgcrypt has some horrendous bugs which upstream refuse to fix,
> for example the broken behaviour relating to setuid binaries
> discussed previously here, and the hard coded behaviour which
> makes it unsuitable for use in general programs.  See
>
> "libgcrypt brain dead?" 
> 3c5cf5261003081534s5202413dw4d93c80db1a30...@mail.gmail.com
>
> Until these major issues are fixed, it's simply unusable.
>
> Ideally, the software relying on the broken behaviour needs fixing,
> and then libgcrypt can remove this idiotic special casing.

So, could we document we different pitfall of crypto library on the
debian wiki ?

Bastien
>
>
> Regards,
> Roger
>
> --
>  .''`.  Roger Leigh
>  : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
>  `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
>   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk24SHMACgkQVcFcaSW/uEjBWwCg79wzuLUxd4XWiwFtTX50dub2
> pRcAn1WWxkYyhnp11nAy/eSB7YLSI3Ue
> =JWMd
> -END PGP SIGNATURE-
>
>


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktik5tkxe+pjg6-fvynmrhbdro+b...@mail.gmail.com

Re: Crypto consolidation in debian ?

2011-04-27 Thread Roger Leigh 
On Wed, Apr 27, 2011 at 09:30:05AM -0700, Russ Allbery wrote:
> Bastien ROUCARIES  writes:
> 
> >> Patches to WebAuth to support NSS are welcome, but I'm sure not going to
> >> bother.  Seems like a waste of time to me.  If I were going to port to any
> >> other crypto library, I'd port to gcrypto, not NSS.
> 
> > See also that suse consider to port to nss
> > http://old-en.opensuse.org/SharedCertStore
> 
> That's fine.  They can send me patches too if they want.  :)  I'm still
> not interested; I'd rather put whatever time I had into making gnutls and
> gcrypto better, particularly since I think FIPS certification is just a
> money-making racket.

libgcrypt has some horrendous bugs which upstream refuse to fix,
for example the broken behaviour relating to setuid binaries
discussed previously here, and the hard coded behaviour which
makes it unsuitable for use in general programs.  See

"libgcrypt brain dead?" 
3c5cf5261003081534s5202413dw4d93c80db1a30...@mail.gmail.com

Until these major issues are fixed, it's simply unusable.

Ideally, the software relying on the broken behaviour needs fixing,
and then libgcrypt can remove this idiotic special casing.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: Crypto consolidation in debian ?

2011-04-27 Thread Russ Allbery 
Bastien ROUCARIES  writes:

>> Patches to WebAuth to support NSS are welcome, but I'm sure not going to
>> bother.  Seems like a waste of time to me.  If I were going to port to any
>> other crypto library, I'd port to gcrypto, not NSS.

> See also that suse consider to port to nss
> http://old-en.opensuse.org/SharedCertStore

That's fine.  They can send me patches too if they want.  :)  I'm still
not interested; I'd rather put whatever time I had into making gnutls and
gcrypto better, particularly since I think FIPS certification is just a
money-making racket.

-- 
Russ Allbery (r...@debian.org)   


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vcxz8xo2@windlord.stanford.edu

Re: Crypto consolidation in debian ?

2011-04-27 Thread Bastien ROUCARIES 
On Wed, Apr 27, 2011 at 12:29 PM, Bastian Blank  wrote:
> On Wed, Apr 27, 2011 at 11:40:14AM +0200, Bastien ROUCARIES wrote:
>> On Wed, Apr 27, 2011 at 1:05 AM, Russ Allbery  wrote:
>> > Patches to WebAuth to support NSS are welcome, but I'm sure not going to
>> > bother.  Seems like a waste of time to me.  If I were going to port to any
>> > other crypto library, I'd port to gcrypto, not NSS.
>> Gcrypto is GPL and thus incompatible with a lot of crypto package
>> unfortunatly. Not good for consolidation
>
> So is libnss, at least the version on my workstation. Your point taken?
>
> Oh. And parts are 4-clause BSD (if I read this correctly).

Debian copyright is out of date, the close was removed by berkeley and
reflected on the source...

The main point is the FIPS 140 certification for external software if
using some simple rules documented at
http://www.mozilla.org/projects/security/pki/nss/fips/secpolicy.pdf

Bastien
>
> Bastian
>
> --
> ... The prejudices people feel about each other disappear when they get
> to know each other.
>                -- Kirk, "Elaan of Troyius", stardate 4372.5
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: http://lists.debian.org/20110427102932.ga2...@wavehammer.waldi.eu.org
>
>


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktiksq62wdqca7nouehxgza8ehna...@mail.gmail.com

Re: Crypto consolidation in debian ?

2011-04-27 Thread Bastien ROUCARIES 
> Patches to WebAuth to support NSS are welcome, but I'm sure not going to
> bother.  Seems like a waste of time to me.  If I were going to port to any
> other crypto library, I'd port to gcrypto, not NSS.

See also that suse consider to port to nss
http://old-en.opensuse.org/SharedCertStore

Bastien


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/BANLkTimkr59-OymRN=FHV8+E6gH=ic2...@mail.gmail.com

Re: Crypto consolidation in debian ?

2011-04-27 Thread Bastian Blank 
On Wed, Apr 27, 2011 at 11:40:14AM +0200, Bastien ROUCARIES wrote:
> On Wed, Apr 27, 2011 at 1:05 AM, Russ Allbery  wrote:
> > Patches to WebAuth to support NSS are welcome, but I'm sure not going to
> > bother.  Seems like a waste of time to me.  If I were going to port to any
> > other crypto library, I'd port to gcrypto, not NSS.
> Gcrypto is GPL and thus incompatible with a lot of crypto package
> unfortunatly. Not good for consolidation

So is libnss, at least the version on my workstation. Your point taken?

Oh. And parts are 4-clause BSD (if I read this correctly).

Bastian

-- 
... The prejudices people feel about each other disappear when they get
to know each other.
-- Kirk, "Elaan of Troyius", stardate 4372.5


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110427102932.ga2...@wavehammer.waldi.eu.org

Re: Crypto consolidation in debian ?

2011-04-27 Thread Julien Cristau 
On Wed, Apr 27, 2011 at 11:40:14 +0200, Bastien ROUCARIES wrote:

> On Wed, Apr 27, 2011 at 1:05 AM, Russ Allbery  wrote:
> > Bastien ROUCARIES  writes:
> >
> >> I have seen that fedora is trying to consolidate the number of crypto
> >> package shipped [1]. What do you think about this goal ?
> >
> > Patches to WebAuth to support NSS are welcome, but I'm sure not going to
> > bother.  Seems like a waste of time to me.  If I were going to port to any
> > other crypto library, I'd port to gcrypto, not NSS.
> 
> Gcrypto is GPL and thus incompatible with a lot of crypto package
> unfortunatly. Not good for consolidation

If you mean gcrypt, it's LGPL, which should be fine.  So is gnutls
(except for its openssl wrapper).  If you're talking about something
else, what is it?

Cheers,
Julien


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110427101336.go2...@radis.liafa.jussieu.fr

Re: Crypto consolidation in debian ?

2011-04-27 Thread Bastien ROUCARIES 
On Wed, Apr 27, 2011 at 1:05 AM, Russ Allbery  wrote:
> Bastien ROUCARIES  writes:
>
>> I have seen that fedora is trying to consolidate the number of crypto
>> package shipped [1]. What do you think about this goal ?
>
> Patches to WebAuth to support NSS are welcome, but I'm sure not going to
> bother.  Seems like a waste of time to me.  If I were going to port to any
> other crypto library, I'd port to gcrypto, not NSS.

Gcrypto is GPL and thus incompatible with a lot of crypto package
unfortunatly. Not good for consolidation
>
> --
> Russ Allbery (r...@debian.org)               
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: http://lists.debian.org/87liywlikq@windlord.stanford.edu
>
>


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktimi4nf2yco1iwnz2gtjdqfwj5k...@mail.gmail.com

Re: Crypto consolidation in debian ?

2011-04-27 Thread Mike Hommey 
On Wed, Apr 27, 2011 at 10:25:30AM +0200, Marco d'Itri wrote:
> On Apr 27, Bastian Blank  wrote:
> 
> > On Tue, Apr 26, 2011 at 07:20:55PM +0200, Marco d'Itri wrote:
> > > The reason is that the kind of entities which require FIPS 140 probably
> > > also tend to require corporate vendor support, which we do not provide.
> > What is FIPS 140 and why is this important?
> It is a certification required by USG and many financial customers.
> 
> > > If building a package with NSS instead of other libraries does not
> > > causes relevant negative side effects then I think we should do it to
> > > benefit from the improvements which NSS is receiving and to help the
> > > process.
> > No support for /etc/ssl?
> NSS uses a different method to store certificates, but I do not think
> that this is a serious problem.

Fedora supposedly is working on a pkcs#11 module to read from /etc/ssl.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110427082937.ga10...@glandium.org

Re: Crypto consolidation in debian ?

2011-04-27 Thread Marco d'Itri 
On Apr 27, Bastian Blank  wrote:

> On Tue, Apr 26, 2011 at 07:20:55PM +0200, Marco d'Itri wrote:
> > The reason is that the kind of entities which require FIPS 140 probably
> > also tend to require corporate vendor support, which we do not provide.
> What is FIPS 140 and why is this important?
It is a certification required by USG and many financial customers.

> > If building a package with NSS instead of other libraries does not
> > causes relevant negative side effects then I think we should do it to
> > benefit from the improvements which NSS is receiving and to help the
> > process.
> No support for /etc/ssl?
NSS uses a different method to store certificates, but I do not think
that this is a serious problem.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Crypto consolidation in debian ?

2011-04-27 Thread Bastian Blank 
On Tue, Apr 26, 2011 at 07:20:55PM +0200, Marco d'Itri wrote:
> The reason is that the kind of entities which require FIPS 140 probably
> also tend to require corporate vendor support, which we do not provide.

What is FIPS 140 and why is this important?

> If building a package with NSS instead of other libraries does not
> causes relevant negative side effects then I think we should do it to
> benefit from the improvements which NSS is receiving and to help the
> process.

No support for /etc/ssl?

Bastian

-- 
It is more rational to sacrifice one life than six.
-- Spock, "The Galileo Seven", stardate 2822.3


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110427080414.ga...@wavehammer.waldi.eu.org

Re: Crypto consolidation in debian ?

2011-04-26 Thread Russ Allbery 
Bastien ROUCARIES  writes:

> I have seen that fedora is trying to consolidate the number of crypto
> package shipped [1]. What do you think about this goal ?

Patches to WebAuth to support NSS are welcome, but I'm sure not going to
bother.  Seems like a waste of time to me.  If I were going to port to any
other crypto library, I'd port to gcrypto, not NSS.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87liywlikq@windlord.stanford.edu

Re: Crypto consolidation in debian ?

2011-04-26 Thread Bastien ROUCARIES 
On Tue, Apr 26, 2011 at 7:20 PM, Marco d'Itri  wrote:
> On Apr 26, Bastien ROUCARIES  wrote:
>
>> I have seen that fedora is trying to consolidate the number of crypto
>> package shipped [1]. What do you think about this goal ?
> While I believe it to be a worthwhile goal, I have serious doubts that
> we should actively switch packages to NSS when this causes regressions.

Yes main drawback is lack of compression support (see [3]) but it
could be improved

> The reason is that the kind of entities which require FIPS 140 probably
> also tend to require corporate vendor support, which we do not provide.

Even if we do not support corporate, being FIPS 140 is worthwhile from
a security point of view: vendors what care about will provide quick
security fix.
Moreover from a marketing point of view it will be also nice.

> If building a package with NSS instead of other libraries does not
> causes relevant negative side effects then I think we should do it to
> benefit from the improvements which NSS is receiving and to help the
> process.

It will moreover reduce the license mess of openssl... And it is by
itself a worthwhile goal.

Bastien

[3] http://fedoraproject.org/wiki/Nss_compat_ossl

> --
> ciao,
> Marco
>


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktimnylsfo-fmw6v3rnh4cvh6jge...@mail.gmail.com

Re: Crypto consolidation in debian ?

2011-04-26 Thread Marco d'Itri 
On Apr 26, Bastien ROUCARIES  wrote:

> I have seen that fedora is trying to consolidate the number of crypto
> package shipped [1]. What do you think about this goal ?
While I believe it to be a worthwhile goal, I have serious doubts that
we should actively switch packages to NSS when this causes regressions.
The reason is that the kind of entities which require FIPS 140 probably
also tend to require corporate vendor support, which we do not provide.

If building a package with NSS instead of other libraries does not
causes relevant negative side effects then I think we should do it to
benefit from the improvements which NSS is receiving and to help the
process.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Crypto consolidation in debian ?

2011-04-26 Thread Bastien ROUCARIES 
On Tue, Apr 26, 2011 at 5:08 PM, Philipp Kern  wrote:
> On 2011-04-26, Bastien ROUCARIES  wrote:
>> I have seen that fedora is trying to consolidate the number of crypto
>> package shipped [1]. What do you think about this goal ?
>
> Is there any progress on Fedora's effort?  So far it seemed like Vaporware to
> me.  (Given that it's not exactly a Fedora feature that's proposed there,
> which are tracked with progress separately for each release.)

According to wiki history it seems they are progress see [2]

Bastien

[2] 
https://fedoraproject.org/w/index.php?title=CryptoConsolidationScorecard&action=history

> Kind regards
> Philipp Kern
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: http://lists.debian.org/slrnirdo03.9ee.tr...@kelgar.0x539.de
>
>


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktikapcjqbhkzamvzz3efwzhma9j...@mail.gmail.com

Re: Crypto consolidation in debian ?

2011-04-26 Thread Philipp Kern 
On 2011-04-26, Bastien ROUCARIES  wrote:
> I have seen that fedora is trying to consolidate the number of crypto
> package shipped [1]. What do you think about this goal ?

Is there any progress on Fedora's effort?  So far it seemed like Vaporware to
me.  (Given that it's not exactly a Fedora feature that's proposed there,
which are tracked with progress separately for each release.)

Kind regards
Philipp Kern


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnirdo03.9ee.tr...@kelgar.0x539.de

Crypto consolidation in debian ?

2011-04-26 Thread 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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/BANLkTinOV0W=o1tqm1jk2gzhvgpxn3k...@mail.gmail.com