Re: [notmuch] [PATCH] Use libgcrypt for hashing.

2009-11-27 Thread Ingmar Vanhassel
Excerpts from Mikhail Gusarov's message of Sat Nov 28 04:31:15 +0100 2009:
 
 Twas brillig at 21:28:03 27.11.2009 UTC-06 when j...@ocjtech.us did gyre and
 gimble:
 
  JCO Instead of including a private implementation of the SHA1 hash
 
 xserver went this road, and now it has
 --with-sha1=libc|libmd|libgcrypt|libcrypto|libsha1|CommonCrypto in
 configure.

From a distribution  security point of view I'd much rather be able to
choose one hashing library  use that as widely as possible, rather than
having every application ship its own copy.

  JCO This means less code of our own to maintain and
 
 As libsha1 maintainer I'm volunteering to maintain in-tree copy in
 notmuch :)

Right, but on top of that, it would still be preferable to keep the
option for packagers to use a system library instead.
Most distributions have a rather strict policy to use system libraries
over internal copies.

-- 
Exherbo KDE, X.org maintainer
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [notmuch] [PATCH] Use libgcrypt for hashing.

2009-11-27 Thread Jeffrey Ollie
On Fri, Nov 27, 2009 at 9:31 PM, Mikhail Gusarov
dotted...@dottedmag.net wrote:
 Twas brillig at 21:28:03 27.11.2009 UTC-06 when j...@ocjtech.us did gyre and 
 gimble:

  JCO Instead of including a private implementation of the SHA1 hash

 xserver went this road, and now it has
 --with-sha1=libc|libmd|libgcrypt|libcrypto|libsha1|CommonCrypto in
 configure.

I doubt that we'll get to that level of insanity.

  JCO This means less code of our own to maintain and

 As libsha1 maintainer I'm volunteering to maintain in-tree copy in
 notmuch :)

That's great that you're willing to take on the task, but as I do a
lot of work for Fedora I tend to think about these things differently.
 It's not about a project here or there making private copies of some
code, it's about tracking down *all* of the projects that have private
copies of the code when something goes wrong, especially when there
are security implications.

The most famous example is Zlib.  Based upon what Google turned up I
see that you've been around long enough that you should have heard of
the problems the computer world had when security flaws turned up in
Zlib.  There's even a project[1] that developed methods for
identifying vulnerable code in binaries the problem was so pervasive.

A more recent example is a cross-site ajax request vulnerability in
the Prototype JavaScript framework[2].  A lot of projects copied that
code into their repositories as well, and now someone has to track all
of those down and get them fixed as well.

When projects copy code into their repositories like this, it makes
things a lot more difficult for someone else down the road.  Both
Fedora[3] and Debian[4] (and Ubuntu by extension), while not expressly
forbidding the practice, *strongly* recommend against it.  I'd really
recommend reading the Fedora page that explains the policy as it has a
great summation of the problem.

[1] http://www.enyo.de/fw/security/zlib-fingerprint/
[2] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-7220
[3] https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
[4] http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles

-- 
Jeff Ollie
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [notmuch] [PATCH] Use libgcrypt for hashing.

2009-11-27 Thread Jeffrey Ollie
On Fri, Nov 27, 2009 at 9:59 PM, Ingmar Vanhassel ing...@exherbo.org wrote:

 Most distributions have a rather strict policy to use system libraries
 over internal copies.

Fedora:

https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

Debian:

http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles

If there are other distributions out there that have similar policies
I'd be interested in learning about them.

-- 
Jeff Ollie
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch