mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Dennis, Jim" <jdennis@snapserver.com>
To: "'Jeff Garzik'" <jgarzik@mandrakesoft.com>,
	Andreas Dilger <adilger@turbolabs.com>
Cc: "Dennis, Jim" <jdennis@snapserver.com>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: RE: crypto (was Re: Congrats Marcelo,)
Date: Tue, 26 Feb 2002 15:18:56 -0800	[thread overview]
Message-ID: <2D0AFEFEE711D611923E009027D39F2B153AD6@cdserv.meridian-data.com> (raw)



> Andreas Dilger wrote:
>> On Feb 26, 2002  12:38 -0800, Dennis, Jim wrote:
>>>  Now I need to know about the status of several unofficial patches:

>>>       i2c
>>>       Crypto
>>>       FreeS/WAN KLIPS
>>>       LIDS
 
>> No idea.

> I would -love- to see crypto in the mainstream kernel.  Distribution of
> crypto software on kernel.org has been OK for a while now.

> Who knows what the kerneli guys, freeswan, etc. guys think.

> IMO it's time to get a good IPsec implementation in the kernel...

>	Jeff

 I think some people may have misinterpreted my question.  I was actually 
 asking about how soon the maintainers of these unofficial patches will
 be updating their patches to apply cleanly to 2.4.18 (and hopefully in
 conjunction with one another).  I wasn't actually asking when or if these
 would be merged into the mainstream.

 I understand that XFS is not slated for 2.4.x merging; and I presume that
the
 ACL and extended ACL stuff is also slated to remain separate.  I also
understand
 the wariness of the kernel maintainers regarding any inclusion of the
crypto
 code in mainstream given the ongoing U.S. and international political and
legal
 issues that are STILL associated with it.  (Who was it who said that
"reform
 is the enemy of revolution" --- like it or not that seems to be the case
with
 U.S. crypto policy; they've opened the doors enough for most practical
purposes
 leaving a spectre of doubt that they may still have the "right" to control
 the use and export of future cryptographic --- and by extension *other*
software
 --- technologies).  So I understand that the international and KLIPS
patches will
 probably be "unofficial" for the foreseeable future.

 The i2c work seems like a good candidate for inclusion (since lmsensors is
*THE*
 major user of these APIs and it requires the new version.

 As for LIDS, grsecurity, etc: I suspect it will be a cold day in hell
before Linus
 includes any of those into the mainstream.  I think it is sufficient that
he's willing 
 to accommodate the LSM (security module) to provide a common interface to
all of the 
 competing kernel hardening packages.  (I think a bit of consolidation
between the 
 international crypto patch and the LIDS patches might be in order, are they
each
 defining their own versions of the common hashing and encryption
algorithms?).

 The rmap patches are the ones which I would expect to cause the most
debate.  On the
 one hand it seems that they have significant performance and robustness
benefits
 (when the system is pushed to VM pressure) on the other hand I could
understand that
 Marcelo might be VERY reluctant to make such a deep change in a "stable"
series.
 (Linus took a lot of flack for earlier 2.4 VM changes and *he's* the
benevolent
 dictator! --- one can only imagine what will happen to any mortal that
would tempt
 fate so audaciously).  (Anyway, it seems to be a non-issue since you say
that Rik
 isn't even proposing their inclusion; I guess he has just been waiting for
an appropriate
 merge point in 2.5)

 So, I just wanted to know when the (minor) unofficial patches were getting
updated.
 Actually what I'd like is a focal point, perhaps a web site like the old
"big Mama" 
 patches (that Kurt Hewig? used to maintain), which would track and merge
these collections
 of unofficial patches.

 I'll check the FOLK (folk.sourceforge.net) pages ... [click, click]
 ... O.K. those were updated for 2.4.18rc2 so I guess they'll probably be
pretty durn
 close.

 Hmmm.  It seems that I'm rambling and wasting everyone's visual bandwidth.
I'll go 
 away now.  ;)




             reply	other threads:[~2002-02-26 23:17 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-26 23:18 Dennis, Jim [this message]
2002-02-27  0:24 ` Chris Wright
  -- strict thread matches above, loose matches on Subject: below --
2002-02-27  0:42 Dennis, Jim
2002-02-27  1:02 ` Chris Wright
2002-02-26 20:38 Congrats Marcelo, Dennis, Jim
2002-02-26 21:06 ` Andreas Dilger
2002-02-26 21:15   ` crypto (was Re: Congrats Marcelo,) Jeff Garzik
2002-02-26 22:33     ` Rik van Riel
2002-02-27 21:15       ` Michael H. Warfield
2002-02-27 21:57         ` Rik van Riel
2002-02-27 22:29           ` Michael H. Warfield
2002-02-27 23:06             ` Rik van Riel
2002-02-26 21:35   ` Robert Love
2002-02-26 21:40     ` arjan
2002-02-26 21:47       ` Robert Love
2002-02-24 23:51         ` Daniel Phillips
2002-02-28 22:32           ` Bill Davidsen
2002-03-01  9:50             ` Francois Romieu
2002-02-27  9:41     ` Francois Romieu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2D0AFEFEE711D611923E009027D39F2B153AD6@cdserv.meridian-data.com \
    --to=jdennis@snapserver.com \
    --cc=adilger@turbolabs.com \
    --cc=jgarzik@mandrakesoft.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®