Mailing List Archive

>
>
> Hello All,
> My name is Geoff White and I have the wonderful task of
> dropping some version of SHTTP support into Apache.
> Here at EIT, we need SHTTP in a UN*X based server for a
> number of projects and it seemed that putting the functionality
> into Apache is "the right thing". I would like to correspond with
> folks who have done similar types of additions (like the PEM
> hacks) or other groups who are about to do similar work.

Well. I was also planning to put in SSL/SHTTP support. I'm only too happy
to work with others to achieve this. As far as I can see we have two major
problems; SSL is kinda complicated, and we have this blasted ITAR/SSLRef/SSLeay
stuff to deal with. By the looks of things, you are in the States, so you
can handle SSLRef, and I'm not, so I can handle SSLeay.

Does anyone know what we have to do in terms of code to avoid being arrested?
I've heard that even exporting code with encryption hooks but no encryption
code is illegal (in the US).

I have come across various others interested in this. I offer to (attempt to)
coordinate the various groups.

Cheers,

Ben.

--
Ben Laurie Phone: +44 (181) 994 6435
Freelance Consultant Fax: +44 (181) 994 6472
and Technical Director Email: ben@algroup.co.uk
A.L. Digital Ltd,
London, England.

>
> Ben L:
> [shttp et al...]
> > Does anyone know what we have to do in terms of code to avoid being arrested?
> > I've heard that even exporting code with encryption hooks but no encryption
> > code is illegal (in the US).
>
> A while back now, NCSA were told to remove all their PGP/PEM functionality
> from NCSA 1.3/1.4, which amounted to the removal of some explicit hooks
> in the code. Apache was based on 1.3 and so, to avoid the same legal
> problems we decided also to remove that functionality from Apache.
>
> At about the same time Rob Thau came up with the modular system from
> Shambhala which Apache adopted. The system would, in theory, allow
> 3rd-party developers to design their own modules to interface with the
> Apache API. Clearly there is scope for a non-Apache Group module to
> be written by someone and then made available to the general public,
> subject to the legal considerations pertaining in their own country.
>
> For example, a South African resident could design a PGP/PEM encryption
> module and make it available for non US citizens to use. Similar works could
> be made available by US residents but then would be restricted to
> distribution to only other US residents - no exporting of that new
> functionality across borders would be allowed.
>
> It is important, IMHO, that Apache Group's work, meaning the code we
> distribute from hyperreal and to the mirror sites, should be free from
> any legally questionable functionality. This will ensure that the
> main focus of the group's work can proceed unhampered. If Apache is
> maintained as an 'open' system, with a well documented API then there
> is no reason for the server itself to contain any code that might
> harm the project, and also there is every likelihood that 3rd party
> developers will be able to add functionality to the server.
>
> So:
>
> 1) there's nothing to stop other people from developing
> SHTTP/SSL/PGP/PEM whatever modules, and managing their
> distribution and maintainence independently of the Apache Group

OK, but since SSL works at the connection level, there would have to be
some hooks to allow us to take over accept, bind, read, write and the like.
This is undoubtedly related to the OS independence stuff.

> 2) the server as distributed should not contain any code
> that would break a nation's law

Hmm, whilst this is a nice principle, it may get a bit difficult in practise.
We'll probably have to settle for most nations, not all.

>
> > I have come across various others interested in this. I offer to (attempt to)
> > coordinate the various groups.
>
> You will find some useful pointers to this in the mailing list's archives,
> available on apache.org, DNS permitting.

Pointers to what, exactly?

> > Ben Laurie Phone: +44 (181) 994 6435
> Ay.

Cheers,

Ben.

--
Ben Laurie Phone: +44 (181) 994 6435
Freelance Consultant Fax: +44 (181) 994 6472
and Technical Director Email: ben@algroup.co.uk
A.L. Digital Ltd,
London, England.

Ben L:
[shttp et al...]
> Does anyone know what we have to do in terms of code to avoid being arrested?
> I've heard that even exporting code with encryption hooks but no encryption
> code is illegal (in the US).

A while back now, NCSA were told to remove all their PGP/PEM functionality
from NCSA 1.3/1.4, which amounted to the removal of some explicit hooks
in the code. Apache was based on 1.3 and so, to avoid the same legal
problems we decided also to remove that functionality from Apache.

At about the same time Rob Thau came up with the modular system from
Shambhala which Apache adopted. The system would, in theory, allow
3rd-party developers to design their own modules to interface with the
Apache API. Clearly there is scope for a non-Apache Group module to
be written by someone and then made available to the general public,
subject to the legal considerations pertaining in their own country.

For example, a South African resident could design a PGP/PEM encryption
module and make it available for non US citizens to use. Similar works could
be made available by US residents but then would be restricted to
distribution to only other US residents - no exporting of that new
functionality across borders would be allowed.

It is important, IMHO, that Apache Group's work, meaning the code we
distribute from hyperreal and to the mirror sites, should be free from
any legally questionable functionality. This will ensure that the
main focus of the group's work can proceed unhampered. If Apache is
maintained as an 'open' system, with a well documented API then there
is no reason for the server itself to contain any code that might
harm the project, and also there is every likelihood that 3rd party
developers will be able to add functionality to the server.

So:

1) there's nothing to stop other people from developing
SHTTP/SSL/PGP/PEM whatever modules, and managing their
distribution and maintainence independently of the Apache Group

2) the server as distributed should not contain any code
that would break a nation's law

> I have come across various others interested in this. I offer to (attempt to)
> coordinate the various groups.

You will find some useful pointers to this in the mailing list's archives,
available on apache.org, DNS permitting.

> Cheers,
> Ben.
> Ben Laurie Phone: +44 (181) 994 6435

Thoughts?

Cheers,
Ay.

> > 1) there's nothing to stop other people from developing
> > SHTTP/SSL/PGP/PEM whatever modules, and managing their
> > distribution and maintainence independently of the Apache Group
>
> OK, but since SSL works at the connection level, there would have to be
> some hooks to allow us to take over accept, bind, read, write and the like.
> This is undoubtedly related to the OS independence stuff.

Yep. There are mumblings that Apache might be a good prospect for porting to
NT, so there's another reason for trying to go for OS independence at
some time after 1.0

> > 2) the server as distributed should not contain any code
> > that would break a nation's law
>
> Hmm, whilst this is a nice principle, it may get a bit difficult in practise.
> We'll probably have to settle for most nations, not all.

Well, I was referring to the 'PGP is munitions' stuff that's rampant
in the states right now. I'm not aware of any other 'laws' that we'd
be infringing. I'd rather that there was one single source tree for
the server, with a decent API for extra funky stuff to be coded up, rather
than their being an Apache-1.0(Europe), Apache-1.0(US) distinction. I
note that Netsite is bundled in two variants, the US version carrying
some encryption technology that can't be exported. I don't think that's
a useful precedent to follow; if modules can't do *everything* we want
then we should try to ammend the module/API, rather than carry two or more
complete source trees.

> > > I have come across various others interested in this. I offer to (attempt to)
> > > coordinate the various groups.
> >
> > You will find some useful pointers to this in the mailing list's archives,
> > available on apache.org, DNS permitting.
>
> Pointers to what, exactly?

Beth Franks (NCSA) contacted Apache Group and told us that we'd better
watch out. There was quite a bit of "To hell with the law" chat before
people wised up and settled for an easy life; removing the hooks. As
for coordinating internet projects, well, none of has a clue ;)

> Cheers,
> Ben.
> Ben Laurie Phone: +44 (181) 994 6435

Cheers, (yeah, it's a drink-oriented culture)
Ay.

Andrew --- as author of the module system (as you were so kind to note),
I feel compelled to note that you can't do *everythign* as plug-in modules,
and in some cases it would be silly to even try. The current module interface
doesn't support anything like the flexibility you'd need for SSL, let alone
variant OS support (another one of your "wouldn't it be neat"s).

rst

> Andrew --- as author of the module system (as you were so kind to note),
> I feel compelled to note that you can't do *everythign* as plug-in modules,
> and in some cases it would be silly to even try. The current module interface
> doesn't support anything like the flexibility you'd need for SSL, let alone
> variant OS support (another one of your "wouldn't it be neat"s).

Yeah, even I knew that much.

> rst

Ay.