[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Status on Proposal for restricted packages

>>"John" == John Hasler <john@dhh.gt.org> writes:

 John> Ben Collins writes:
 >> This isn't just for the software tho. The data related to the
 >> restrictions needs to be persistent, not just in the .deb file, it needs
 >> to stay on the system and the user should be able to reasonably
 >> understand the info.

 John> Which is why the restrictions file, which contains the maintainers
 John> explanation of the restrictions, goes in /usr/doc/<package>.

	Too much burden is being put on the maintainer, as well as
 making the maintainer more liable legally. I dislike this approach,
 this seems to me to be untenable. 

 >> Not true, just the most common ones that we see in almost all restrcited
 >> packages, which is a limited amount.

 John> What is the point in creating an incomplete database that
 John> contains only the common stuff that anyone involved with
 John> restricted packages already knows about?

	What is a restricted package? What is a restricted package
 today may not be one tomorrow, and unencumbvered packages may be
 restricted the next week Who the hell can keep track of all the laws
 in various countres?


 >> This is exaclty what I was stating above, however, I and others can very
 >> easily tell you what ssh has that makes it restricted, but I bet very few
 >> people really know all of the import and export restrictions associated
 >> with it world-wide.

 John> So you agree that the people maintaining restricted packages are the one
 John> who know the subject best.

	Rubbish. I am a security expert. I can maintain things like
 Kerberos and DCE (Frankly, not very many people have experience in
 corporate security). But am I a lawyer? Hell, no I need all the help
 I can get -- a database, maintained by a security list, would be
 immensly helpful.

	I can maintain so called restricted packages (and what s a
 restricted package may change as laws are passed (note -- laws are
 passed evry day). Having a central database that can be maintained by
 a group with members from several countries is better positioned to
 be pro-active.

 >> I'de much rather say "crypto-rsa" than say "ummm, I wonder where this
 >> thing can and can't go?".

 John> Then look in Raul's database.  But do so with the critical eye
 John> of someone who knows something about the subject.  If you need
 John> help, ask on the restrictions mailing-list.  Much more robust
 John> than a central database and a critical piece of software.

	The restrictions mailing list maintains the central
 database. Best of both worlds. I think that the user should be in
 charge of following the laws of their country, and not the
 packager. The latter is untenable.

 >> If a maintainer can't even recognize the type of restriction in his
 >> package, how would he know where the restrictions affect it?

 John> Then what is he doing maintaining a restricted package?

	He is maintaining a pacage. Some government somewhere passes a
 law that restricts it there. So I have to be an international lawyer
 no to package things for Debian? That is not going to severly degrade
 the quality of software in the project?

 John> Let's leave the responsibility for the package with the maintainer who is
 John> responsible for it.  We trust the maintainer with security: why not trust
 John> her with this?

	We are software experts, and hence security of code is
 something in our domain. Security is also something that is logical,
 unlike laws which are not, and change without reason from country to
 country. This argument does much to detract from the stand you are
 attempting to take, since it indicates you have not really thought
 things through.

 A woman without a man is like a fish without a bicycle. Therefore, a
 man without a woman is like a bicycle without a fish.
Manoj Srivastava  <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E

Reply to: